You can inspect and refresh a jscpd duplication scan of a project.
check_duplication – test a code snippet against the last scan to find existing clones (optionally similar JS/TS functions by syntax-tree similarity).
get_file_clones – list all clones involving a given file, biggest first.
get_statistics – get project-wide and per-format duplication stats (files, lines, tokens, clones, duplicated percentages).
check_current_directory – re-scan the project paths and return fresh clone counts and the full duplicate list.
Duplicate code detector for 220+ languages — plus dead code, complexity hotspots, duplication trends over git history, and one health score for the whole codebase. Rust engine, self-contained binary, AI-ready with an MCP server and a token-efficient reporter.
Documentation: https://jscpd.dev
jscpd tokenizes each of its 224 supported formats the way that language defines it — its own comment and string rules, not generic text — then finds duplicated token sequences across files with a rolling Rabin-Karp hash. Opt-in passes catch copies that differ only in names or values (Type-2) or that have a few edited lines (Type-3). See How detection works for the full mechanism, and Supported formats for the full list.
Beyond duplicates, jscpd also finds dead code (--dead-code), ranks files by complexity (--complexity), tracks duplication over git history (--history), and rolls it all into one health score (--health) — see Features below.
# macOS / Linux
curl -fsSL https://jscpd.dev/install.sh | bash
# Windows (PowerShell)
irm https://jscpd.dev/install.ps1 | iex
# No install — run once with npx (Node.js)
npx jscpd .Then scan a project:
jscpd /path/to/codeMethod | Command | Notes |
npm |
| Installs the |
npm ( |
| Same binary, exposed as |
PyPI |
| Platform wheels with both commands; also |
Cargo |
| Builds from crates.io; installs both |
Homebrew |
| macOS / Linux |
Nix |
| Or |
Docker |
| Multi-arch image built from the release binaries |
- uses: kucherenko/jscpd@v5
with:
threshold: 5Uploads SARIF results to GitHub Code Scanning by default. See CI & Pre-Commit Hooks for all inputs and outputs.
Related MCP server: tree-sitter-analyzer
Document | Description |
Installation, CLI reference, reporters, baseline, summary, complexity, dashboard, blame, config file | |
AI reporter, agent skills, MCP server | |
Rust API ( | |
GitHub Action, Docker image, pre-commit hooks | |
npm packages and crates that make up a release | |
All 224 formats with their file extensions | |
One |
jscpd v5 is a Rust engine that ships as a self-contained binary — no runtime required — under two npm names (jscpd installs the jscpd command, cpd installs cpd), on PyPI, crates.io, Homebrew, Nix, Docker, and as a GitHub Action.
Language-aware tokenization — per-format comment and string syntax for all 224 formats, the oxc parser for JavaScript/TypeScript/JSX/TSX, embedded-language extraction for Vue, Svelte, Astro, Markdown and Razor, and keyword/identifier/literal classification, so a clone is a repeated sequence of language tokens, never a repeated run of text (see How detection works)
224 language formats, with cross-format detection (Vue SFC, Svelte, Astro, Markdown) and --cross-formats groups to match clones across JavaScript and TypeScript
Type-2 clones — --ignore-identifiers, --ignore-literals and --ignore-annotations find blocks that differ only in names, literal values or annotations, reported as renamed (see docs)
Type-3 near-miss clones — --max-gap-lines N merges a copy with a few inserted or changed lines into one similar clone with a similarity score; --similarity 0.85 compares whole JavaScript/TypeScript functions by syntax-tree structure, catching renames and scattered edits too (see docs)
Clone kinds everywhere — exact, renamed or similar in the console, JSON (kind, similarity, method), XML, HTML, Xcode, SARIF (jscpd/duplicate-code, jscpd/renamed-code, jscpd/similar-code) and Code Climate output; default runs still report only exact clones
--kind — keep only the clone kinds you care about: --kind renamed, or --kind gap,ast for near-miss clones only. Statistics and --threshold follow the filter; a kind whose detector is off warns, an unknown kind errors (see docs)
15 reporters: console, console-full, json, xml, csv, html, markdown, badge, sarif, codeclimate, openmetrics, ai, xcode, threshold, silent
Clone baseline — gate CI on new duplication only. --baseline .jscpd-baseline.json --fail-on-new-clones[=N] tolerates legacy clones and fails the build on regressions; --baseline-from-ref origin/main does the same without a committed file (see docs)
Exit codes you can gate on — an unknown --format, a missing scan path or a reporter that can't write its file now exit 1 instead of passing with an empty report; --fail-on-empty fails a scan that analyzed no files (see Exit codes)
GitLab-ready reporters — codeclimate (gl-code-quality-report.json) and openmetrics (jscpd-metrics.txt) plug into artifacts:reports
Git blame with side-by-side author comparison (--blame --reporters console-full)
--skip-local — report only clones that cross the scan roots: jscpd packages/api packages/web --skip-local drops pairs inside either tree, keeping only api-to-web duplication
--skip-isolated — ignore duplication between monorepo folders owned by different teams (--skip-isolated "packages/team-a|packages/team-b")
--history — duplication trend over git history: jscpd src --history v5.0.0..HEAD scans every commit in the range and prints a sparkline, a per-commit table with the change between points, the overall trend, and how far --threshold could be tightened (see docs)
--dead-code — find code nothing runs, not just code written twice: unused files, exports, declarations and imports across JavaScript, TypeScript and Python. Builds the import graph from your entry points (package.json, pyproject.toml, framework conventions) and walks it, so dead code cascades — a helper whose only caller is dead gets reported too, each finding with a confidence score and, below 100, why it might be wrong. Also ships standalone as basta (see docs)
--summary — refactoring hotspots straight from the scan: top files and folders by tokens, lines, size, and a complexity estimate (see docs)
--complexity — the complexity ranking alone, without clone detection: most complex files and folders from one tokenizing pass, in the console, ai or json (see docs)
--health — one 0-100 score with a grade, from the share of code that's duplicated, dead, or concentrated in complex files; size-aware, calibrated on 42 open-source projects, extensible with coverage, test or security metrics via --health-input. Console badge, JSON, SVG badge (see docs)
--dashboard — the whole picture on one screen, under the health badge: project size, duplication by clone kind with the most duplicated files, the most complex files, and dead code by category for JavaScript, TypeScript and Python (see docs)
--mcp — built-in MCP server over stdio with fully described tools: point your AI assistant at the binary and it can check snippets for duplication against your codebase, or find structurally similar functions with a similarity argument (see docs)
AI reporter — token-efficient output for LLM pipelines (~79% fewer tokens than console)
Prebuilt for 8 platforms — macOS arm64/x64, Linux arm64/x64 (glibc and musl), Windows arm64/x64
--workers — control parallelism for file tokenization and detection (default: all CPU cores)
Config discovery — .jscpd.json, .config/jscpd.json, or the jscpd key in package.json
Symbolic links are skipped unless --follow-symlinks — v4 followed them by default. With the flag, a file reached through a link is reported by the path it was found at, and a file reachable through several paths is counted once
Quiet in pipelines — tips and sponsor lines print only on an interactive terminal; --no-tips, CI or JSCPD_NO_TIPS switch them off everywhere
See the Rust docs for the full CLI reference and rust/CHANGELOG.md for release notes.
jscpd v4 (TypeScript engine, Node.js API, LevelDB/Redis stores) is maintained on the master-v4 branch and published as jscpd@4 / the latest-4 dist-tag. README-v4.md describes it in one page (install, CLI, API, packages, maintenance policy); the same content is at https://jscpd.dev/getting-started/v4.
Package | Registry | Description |
Installs the | ||
Installs the | ||
npm | Platform binary packages pulled in as optional dependencies: | |
Platform wheels repacked from the release binaries; installs both | ||
CLI crate; installs both | ||
Detection algorithm (Rabin-Karp rolling hash), data models | ||
Source code tokenization (224 formats) | ||
File walking, orchestration, git blame — the library entry point | ||
Output formatting (15 reporters, duplication and dead code) | ||
npm / crates.io | Dead code detection — unused files, exports, symbols and imports for JavaScript, TypeScript and Python. Installs the |
The jscpd npm package is downloaded 10M+ times per month, and ~5,000 repositories declare it on GitHub's dependents graph.
Bundled by analysis platforms:
GitHub Super Linter — official GitHub linter aggregator, bundles jscpd as its copy/paste detector and runs it by default; 15,500+ workflow files on GitHub reference Super Linter (as of Sep 2026)
MegaLinter — open-source linter aggregator for CI, ships jscpd in every flavor including ci_light
Codacy — automated code analysis platform, jscpd powers the duplication engine
Explicitly enabled in Super Linter (VALIDATE_JSCPD: true) by dozens of public repositories, including:
A2A — Google's Agent2Agent protocol (25k+ stars)
RimSort — mod manager for RimWorld (1.2k+ stars); also runs jscpd directly with its own .jscpd.json
Contact Center AI samples — official Google Cloud samples, with a dedicated jscpd config
Drifty — open-source download manager
Used in notable projects:
OpenClaw — personal AI assistant, runs jscpd as a duplication gate in its check scripts
DeepSeek Harness — DeepSeek's plugin harness, jscpd config in CI
degit — Rich Harris's project scaffolder
MEGA webclient — the MEGA.nz web client
Alibaba AppWorks — embeds jscpd as a library
OVHcloud manager — OVHcloud's customer control panel
KiroCrew — self-improving persistent development workspace
Compared against other copy/paste detectors on the fixtures/ corpus (547 files, 150+ formats), default thresholds, wall-clock time on Apple Silicon:
Tool | Time | Files | Clones | Dup Lines |
jscpd | 84ms | 347 | 212 | 9,133 |
jscpd-rs | 111ms | 360 | 222 | 10,317 |
Duplo | 162ms | 319 | 518 | 13,049 |
Fallow dupes | 164ms | 34 | 10 | 3,137 |
Simian | 964ms | 547 | 424 | 15,351 |
PMD CPD | 35.980s | 71 | 56 | 2,267 |
Methodology, cross-format detection and AI-token-efficiency comparisons: benchmark/BENCHMARK.md. Re-run with benchmark/benchmark.sh.
jscpd integrates into AI-powered workflows through three mechanisms:
Token-efficient output for LLM pipelines (~79% fewer tokens than the default console reporter):
jscpd --reporters ai /path/to/source # compact clone list
jscpd --reporters ai --summary /path/to/source # + compact codebase summary
jscpd --reporters ai --complexity /path/to/source # most complex files, no clone detectionInstallable skills that teach AI coding assistants how to use jscpd, refactor detected duplications, and clean up a codebase more broadly:
Skill | Purpose | Install |
Tool reference — CLI options, AI reporter format, config syntax |
| |
Guided refactoring workflow — read clones, choose strategy, apply, verify |
| |
Broader health pass — fix duplication, then remove/refactor dead code, then simplify the biggest/most complex files, prioritized from |
|
After installation, ask your agent to "find and fix code duplication" and it will invoke jscpd with the right options and act on the results — or "clean up this codebase" for the broader pass.
jscpd --mcp /path/to/project scans once and serves the Model Context Protocol over stdio, so an assistant can check any snippet for duplication against the codebase on demand, list a file's clones, re-scan the working directory, and look for structurally similar functions by passing similarity.
See AI-Ready docs for full details.
If jscpd is part of your research, cite it via the repository's CITATION.cff (GitHub's "Cite this repository" button produces BibTeX and APA) or with:
@software{jscpd,
title = {jscpd: copy/paste detector for programming source code},
author = {Kucherenko, Andrey},
year = {2026},
version = {5.3.0},
license = {MIT},
url = {https://github.com/kucherenko/jscpd},
}See CONTRIBUTING.md for the development setup, test policy, and pull request requirements. In short:
cd rust
cargo nextest run --workspace
cargo clippy --workspace --all-targets -- -D warnings
cargo fmt --all --checkSecurity issues go through the security policy, not public issues.
Thank you to all our backers! 🙏 [Become a backer]
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
MIT © Andrey Kucherenko
Re-scan the paths the server was started with and return the fresh clone list and counts. Use it after creating, editing or deleting files, so that check_duplication, get_file_clones and get_statistics answer from current content. Returns {files, clones, returned, duplications[]} with the same duplication shape as get_file_clones, biggest first. Reads the filesystem only; it never writes. The scan is synchronous and can take a few seconds on large projects; results replace the previous scan entirely.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of clones to include in the response. 'clones' always carries the untruncated total, so a small limit still tells you how much was found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, destructiveHint. The description adds valuable context beyond those: it is synchronous, can take seconds on large projects, reads the filesystem only (reinforcing but not contradicting annotations), and replaces the previous scan entirely. This extra performance and state-replacement info is useful and not redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero fluff. The primary purpose and usage trigger are front-loaded, followed by output shape, side effects, and performance notes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description fully compensates: it specifies the return shape (files, clones, returned, duplications[]), notes the duplication shape matches get_file_clones, and covers time/state behavior. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'limit' is 100%, with a clear description already explaining its purpose and the untruncated 'clones' field. The description adds no new parameter-specific semantics beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Re-scan the paths') and resource ('clone list and counts'), and explicitly ties it to refreshing content for sibling tools (check_duplication, get_file_clones, get_statistics). The purpose is unambiguous and distinct from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use it after creating, editing or deleting files' and explains why (so the other tools answer from current content). This clearly conditions the tool's usage on a specific scenario and establishes its role as a prerequisite, leaving no ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a code snippet duplicates code that already exists in the scanned project. Use it before writing or committing a function, class or block, to find the existing copy you should reuse instead. Detection is token-based with the server's --min-tokens / --min-lines thresholds: a snippet shorter than the threshold returns count 0 with a 'note' explaining why. Returns {format, count, returned, duplications[]} where each duplication has 'file', 'fileStartLine', 'fileEndLine', 'snippetStartLine', 'snippetEndLine', 'tokens' and 'kind' (exact, renamed or similar), biggest match first. With 'similarity' below 1, the response also carries 'similar[]' and 'similarCount': project functions whose syntax-tree structure resembles each function in the snippet (JavaScript/TypeScript only), each with 'file', 'name', line ranges and a 'similarity' ratio. Does not modify the project or the scan; the snippet is compared against the last scan, so call check_current_directory first if files changed.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to check, verbatim (whole functions or blocks work best; it must reach the server's --min-tokens threshold, 50 tokens by default) | |
| limit | No | Maximum number of duplications to include in the response. 'count' always carries the untruncated total, so a small limit still tells you how much was found. | |
| format | Yes | Language of the snippet: a jscpd format name such as 'javascript', 'typescript', 'python', 'java', or a file extension such as 'js', 'py' (run `jscpd --list` for all 224). Unknown values return an error naming the problem. | |
| similarity | No | Also return project functions whose syntax-tree structure is similar to the snippet's functions, when the similarity ratio reaches this value. 1 means exact matches only (no 'similar' section); 0.85 catches renames, literal changes and one-line edits; 0.7 tolerates a couple of added or removed statements. Defaults to the server's --similarity setting (1 unless configured). JavaScript/TypeScript only; other formats ignore it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior; the description reinforces this with 'Does not modify the project or the scan' and adds the nuance of comparing against the last scan. It also discloses token-based detection, the threshold effect on results, and the JavaScript/TypeScript limitation for similarity, which are not captured in annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficiently organized: purpose, usage, detection logic, return structure, similarity behavior, and side-effects in logical order. Every sentence carries actionable information; there is no fluff or repetition. The length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers everything an agent needs: purpose, usage timing, prerequisites, parameter semantics, return format with field names, and behavioral caveats (token threshold, language restriction). Even without an output schema, the agent can predict the response structure and understand edge cases. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema. For 'code' it explains the verbatim requirement and the token threshold; for 'limit' it clarifies that 'count' always gives the untruncated total; for 'format' it explains jscpd naming and error behavior; and for 'similarity' it details what different values imply (0.85 catches renames, 0.7 tolerates added statements). This goes far beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Check whether a code snippet duplicates code that already exists in the scanned project.' It then gives a concrete use case ('Use it before writing or committing a function, class or block'), making the purpose unmistakable. The tool is clearly distinct from siblings like get_file_clones and get_statistics, which focus on per-file clones and aggregate stats respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('before writing or committing') and provides a critical prerequisite ('call check_current_directory first if files changed'), which is essential for correct operation. It also explains the threshold behavior that yields count 0. It does not name alternative tools, but the context is sufficient for an agent to know when this tool applies versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every clone from the last scan that involves one file, so you know which other files share code with it. Use it before refactoring, splitting or deleting a file, or after editing it (re-scan first with check_current_directory). Returns {file, clones, returned, duplications[]} where each duplication has 'format', 'fileA', 'startA', 'endA', 'fileB', 'startB', 'endB', 'lines', 'tokens' and 'kind', biggest clone first; the requested file may appear as fileA or fileB. A path that was not part of the scan returns clones 0. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The file to inspect, either relative to the scan root exactly as paths appear in other tool results (e.g. 'src/cart.js') or absolute | |
| limit | No | Maximum number of clones to include in the response. 'clones' always carries the untruncated total, so a small limit still tells you how much was found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: clones are from the last scan, results are ordered biggest first, the requested file may appear as fileA or fileB, and a path outside the scan returns clones 0. It also explains that the 'clones' field carries the untruncated total regardless of the limit. This enriches the agent's understanding beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, with every sentence adding value: purpose, usage, return structure, edge case, and read-only nature. It is front-loaded with the core action and well-structured, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the return shape, including the fields in each duplication and the meaning of 'clones' vs 'returned'. It also addresses the edge case for unscanned paths and the prerequisite re-scanning step. For a tool with no output schema, this is comprehensive and sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (path and limit) with descriptions and examples. The tool description does not add additional parameter semantics beyond what the schema provides, which matches the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List every clone from the last scan that involves one file'. It uses a specific verb and resource, and clarifies the purpose by explaining it helps identify other files sharing code. It also mentions the use case context, which distinguishes it from siblings like check_duplication by focusing on a single file's clones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Use it before refactoring, splitting or deleting a file, or after editing it (re-scan first with check_current_directory)'. It also notes the edge case of a path not in the scan, which helps the agent understand when results may be empty. This is clear guidance on when to use the tool and how to prepare (re-scanning).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the duplication statistics of the last scan: for the whole project and per format, the number of files, lines and tokens analyzed, the number of clones, and the duplicated lines and tokens with their percentages. Use it to judge overall duplication or to compare before and after a refactoring (call check_current_directory in between). Takes no arguments and is read-only; it reflects the last scan, not the files on disk right now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description adds the key non-obvious behavior: results reflect the last scan, not the files on disk right now. This is valuable context beyond the annotations and prevents misinterpretation of stale data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet informative, with the core purpose front-loaded and usage guidance appended. Every sentence adds value; there is no fluff. The structure is easy to parse despite the dense metric list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and annotations covering safety, the description fully specifies what the tool returns and when to use it. It also flags the staleness caveat, making it complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the schema already documents everything. The description adds no parameter details, but the baseline for zero-parameter tools is 4, and no additional explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports duplication statistics from the last scan, enumerating specific metrics (files, lines, tokens, clones, percentages). It differentiates from siblings by focusing on project-wide stats rather than file-specific clones or directory state, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it: to judge overall duplication or compare before/after a refactoring, with a specific instruction to call check_current_directory in between. It does not name alternatives directly, but the context implies it is not for current disk state, which provides adequate guidance without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v5.2.0check_current_directory3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / defaultAdded value: +100Input schema / properties / limit / descriptionPrevious value: -"Maximum number of clones to include in the response (default 100); 'clones' always carries the untruncated total"New value: +"Maximum number of clones to include in the response. 'clones' always carries the untruncated total, so a small limit still tells you how much was found."check_duplication6 fields changedInput schema / properties / code / descriptionPrevious value: -"Source code snippet to check"New value: +"The source code to check, verbatim (whole functions or blocks work best; it must reach the server's --min-tokens threshold, 50 tokens by default)"Input schema / properties / format / descriptionPrevious value: -"Language format (javascript, python, ...) or file extension (js, py, ...); see `cpd --list`"New value: +"Language of the snippet: a jscpd format name such as 'javascript', 'typescript', 'python', 'java', or a file extension such as 'js', 'py' (run `jscpd --list` for all 224). Unknown values return an error naming the problem."Input schema / properties / format / examplesAdded value: +[
+ "javascript",
+ "python",
+ "ts"
+]Input schema / properties / limit / defaultAdded value: +100Input schema / properties / limit / descriptionPrevious value: -"Maximum matches to include in the response (default 100); 'count' always carries the untruncated total"New value: +"Maximum number of duplications to include in the response. 'count' always carries the untruncated total, so a small limit still tells you how much was found."Input schema / properties / similarityAdded value: +{
+ "description": "Also return project functions whose syntax-tree structure is similar to the snippet's functions, when the similarity ratio reaches this value. 1 means exact matches only (no 'similar' section); 0.85 catches renames, literal changes and one-line edits; 0.7 tolerates a couple of added or removed statements. Defaults to the server's --similarity setting (1 unless configured). JavaScript/TypeScript only; other formats ignore it.",
+ "examples": [
+ 0.85
+ ],
+ "exclusiveMinimum": 0,
+ "maximum": 1,
+ "type": "number"
+}get_file_clones4 fields changedInput schema / properties / limit / defaultAdded value: +100Input schema / properties / limit / descriptionPrevious value: -"Maximum clones to include in the response (default 100); 'clones' always carries the untruncated total"New value: +"Maximum number of clones to include in the response. 'clones' always carries the untruncated total, so a small limit still tells you how much was found."Input schema / properties / path / descriptionPrevious value: -"File path, relative to the scan root (as shown in other tool results) or absolute"New value: +"The file to inspect, either relative to the scan root exactly as paths appear in other tool results (e.g. 'src/cart.js') or absolute"Input schema / properties / path / examplesAdded value: +[
+ "src/cart.js"
+]get_statistics1 field changedInput schema / additionalPropertiesAdded value: +falsev0.1.0check_current_directorycheck_duplicationget_file_clonesget_statisticsScored across 4 tools
Each tool targets a distinct workflow stage: refreshing the scan, checking a snippet, listing clones by file, and reporting aggregate statistics. Although check_current_directory also returns a clone list, its refresh role is clearly separated from the query tools by the descriptions.
All tool names use a consistent lowercase snake_case pattern with an imperative verb (check/get) followed by a noun phrase. The naming makes each tool's target and action immediately identifiable.
Four tools is a well-scoped set for a code-duplication server: rescan, snippet-level detection, file-level clone listing, and aggregate statistics. Each tool earns its place without redundancy.
The tool set covers the full workflow: refresh the scan state, then query clones by snippet, by file, or by project statistics. check_current_directory also returns the full clone list, so there is no missing path to raw duplication results.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Source code plagiarism, peer similarity, and AI-generated-code detection for AI agents.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.