Skip to main content
Glama
kucherenko

jscpd

Official
by kucherenko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Project duplication statistics

get_statistics
Read-onlyIdempotent

Report duplication statistics from the last jscpd scan for chosen clone kinds to assess overall duplication or compare before and after refactoring.

Instructions

Report the duplication statistics of the last scan, for the clones of the kinds asked: for the whole project and per format, the files, lines and tokens analyzed, the clones, and the duplicated lines and tokens with their percentages, plus the number of clones of each kind ('byKind'). Use it to judge overall duplication, or to compare before and after a refactoring (call check_current_directory in between). It reflects the last scan, not the files on disk now.

Input Schema

NameRequiredDescriptionDefault
kindsNoThe kinds of clone to look for: exact (type1), renamed (type2), similar (type3; 'gap' or 'ast' for one of its two mechanisms) and semantic (type4). Without it: exact, what jscpd reports with this server's options. Renamed and similar clones may need one scan more, and semantic ones run an embedding model, which takes a while the first time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.4.2
    • addedInput schema / properties / kinds
      Added value: +{
+  "description": "The kinds of clone to look for: exact (type1), renamed (type2), similar (type3; 'gap' or 'ast' for one of its two mechanisms) and semantic (type4). Without it: exact, what jscpd reports with this server's options. Renamed and similar clones may need one scan more, and semantic ones run an embedding model, which takes a while the first time.",
+  "examples": [
+    [
+      "exact",
+      "renamed",
+      "similar"
+    ],
+    [
+      "semantic"
+    ]
+  ],
+  "items": {
+    "enum": [
+      "exact",
+      "renamed",
+      "similar",
+      "gap",
+      "ast",
+      "semantic",
+      "type1",
+      "type2",
+      "type3",
+      "type4"
+    ],
+    "type": "string"
+  },
+  "type": "array",
+  "uniqueItems": true
+}
  2. Changed1 schema field changedv5.2.0
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses important snapshot semantics: it reflects the last scan, not the files currently on disk. It also enumerates the reported statistics, including the 'byKind' breakdown. It does not cover cost or timing details, though those appear in the parameter schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and the key caveat about the last scan. The first sentence is dense and long, but each part carries useful information and the later sentences add workflow guidance efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does a good job listing the returned statistics and explaining the stale-scan behavior. It omits precise output shape details, but gives enough for an agent to understand what the call yields and when to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the sole 'kinds' parameter is fully documented in the schema, including defaults, enum meanings, and performance notes. The description only alludes to 'the clones of the kinds asked' and does not add meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Report the duplication statistics of the last scan') and clarifies the aggregate scope ('whole project and per format'), which helps distinguish it from per-file tools like get_file_clones. It does not explicitly contrast with check_duplication, so sibling differentiation is good but not complete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage contexts: judging overall duplication and comparing before/after a refactoring, with the concrete instruction to call check_current_directory in between. It does not state when not to use it or name get_file_clones as the alternative for per-file clone data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools