Skip to main content
Glama

dedup_scan

Read-onlyIdempotent

Scan stored memories to surface likely duplicate or contradictory pairs, returning similarity scores and candidates for review before linking, editing, or forgetting.

Instructions

Surface likely-duplicate/contradictory memory pairs.

Lexical overlap over near-identical text -- each pair carries its method. Two takes on one subject in different words do not surface here. Same-domain/session checkpoint pairs are excluded (timelines, not dups) and checkpoint pairs rank below durable-type pairs. Not an automatic merge -- returns candidate pairs + similarity score for the agent to review and decide (link_memories / edit_memory / forget as appropriate).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoone memory type, as search() takes it; empty is every type.
limitNothe most pairs to return.
domainNoscans a path and everything nested under it, which is usually what you want: near-duplicates collect between a module and its own routines.
offsetNowhere the page starts; `next_offset`, when present, starts the next.
thresholdNothe similarity, 0 to 1, a pair must reach to be listed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.16.1
    • addedInput schema / properties / domain / description
      Added value: +"scans a path and everything nested under it, which is usually what you want: near-duplicates collect between a module and its own routines."
    • removedInput schema / properties / domain / title
      Removed value: -"Domain"
    • addedInput schema / properties / limit / description
      Added value: +"the most pairs to return."
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "where the page starts; `next_offset`, when present, starts the next.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / threshold / description
      Added value: +"the similarity, 0 to 1, a pair must reach to be listed."
    • removedInput schema / properties / threshold / title
      Removed value: -"Threshold"
    • addedInput schema / properties / type / description
      Added value: +"one memory type, as search() takes it; empty is every type."
    • removedInput schema / properties / type / title
      Removed value: -"Type"
    • removedInput schema / title
      Removed value: -"dedup_scanArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "items": {
      -        "additionalProperties": true,
      -        "type": "object"
      -      },
      -      "title": "Result",
      -      "type": "array"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "dedup_scanOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish the read-only, idempotent, non-destructive safety profile, and the description adds real value beyond that: the exclusion rules, the ranking behavior, and the fact that it returns candidates plus a similarity score for human/agent judgment rather than merging. This is exactly the useful context annotations cannot carry.

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 is front-loaded in the first line, and each subsequent sentence adds a distinct constraint (exclusions, ranking, non-merge semantics). The parenthetical density adds minor friction but nothing is wasted.

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?

No output schema exists, but the description compensates by describing the return shape (candidate pairs, similarity score, method field) and the intended follow-up actions. Combined with the strong annotation set, an agent has enough to call and act on the result.

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%, so the parameters are already documented; the description only adds a modest hint for domain (nested-path behavior) and references the method field on returned pairs (an output detail, not a param). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb+resource (surface duplicate/contradictory memory pairs) and immediately scopes what it will and will not return: lexical-overlap near-identical text only, with different-words takes explicitly excluded. This distinguishes it from siblings like search, recall, and timeline without requiring schema inspection.

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 clear negative guidance (same-domain/session checkpoint pairs excluded, checkpoint pairs rank below durable-type pairs) and clarifies it is not an automatic merge, routing the agent to link_memories/edit_memory/forget afterward. It falls short of explicitly naming the alternative tool for other scanning needs, so it lands at 4 rather than 5.

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