Skip to main content
Glama

List the clones of one file

get_file_clones
Read-onlyIdempotent

List every clone from the last scan involving a file to see which other files share code before refactoring, splitting, or deleting it.

Instructions

List every clone of the last scan that involves one file, to see which other files share code with it. Use it before refactoring, splitting or deleting a file. Returns {file, kinds, clones, returned, duplications[]}, each duplication with 'kind', 'format', 'fileA', 'startA', 'endA', 'fileB', 'startB', 'endB', 'lines' and 'tokens' ('similarity' and 'method' for similar and semantic ones), biggest first; the file may be fileA or fileB. A path that was not part of the scan gets clones 0 and a 'note'.

Input Schema

NameRequiredDescriptionDefault
pathYesThe file, relative to the scan root as other results show paths (e.g. 'src/cart.js'), or absolute.
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.
limitNoMaximum number of clones in the response. 'clones' always carries the full count, so a small limit still tells you how much was found.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv5.4.2
    • addedInput schema / additionalProperties
      Added value: +false
    • 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
      +}
    • changedInput schema / properties / limit / description
      Previous 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."New value: +"Maximum number of clones in the response. 'clones' always carries the full count, so a small limit still tells you how much was found."
    • changedInput schema / properties / path / description
      Previous 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"New value: +"The file, relative to the scan root as other results show paths (e.g. 'src/cart.js'), or absolute."
  2. Changed4 schema fields changedv5.2.0
    • addedInput schema / properties / limit / default
      Added value: +100
    • changedInput schema / properties / limit / description
      Previous 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."
    • changedInput schema / properties / path / description
      Previous 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"
    • addedInput schema / properties / path / examples
      Added value: +[
      +  "src/cart.js"
      +]
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description goes beyond them: it discloses the ordering (biggest first), the edge case where an unscanned path returns 0 clones plus a 'note', and the cost/latency caveats for semantic clones and extra scans.

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?

Purpose, usage, and return shape are front-loaded in that order with no filler sentences. The long enumeration of return fields is dense but earns its place given there is no output schema.

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

Completeness5/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 fully compensates by specifying the response envelope, per-clone fields, ordering, and the not-found shape. An agent has everything needed to call and interpret it.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining that results may place the requested file as either fileA or fileB, and by describing the unscanned-path outcome that affects the 'path' parameter. It does not elaborate on kinds/limit beyond the schema, so not a 5.

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

Purpose5/5

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

Specific verb and resource — 'List every clone of the last scan that involves one file' — plus a scoping phrase ('which other files share code with it') that separates it from siblings like check_duplication and get_statistics.

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?

Gives a concrete usage context ('before refactoring, splitting or deleting a file'), which is clear guidance on when to reach for it. It does not name an alternative tool or state when not to use it, so it falls short of a 5.

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