# Mcp Deduplicator

> >

- **Type:** Skill
- **Install:** `agentstack add skill-sandeeprdy1729-claude-design-skill-mcp-deduplicator`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Sandeeprdy1729](https://agentstack.voostack.com/s/sandeeprdy1729)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [Sandeeprdy1729](https://github.com/Sandeeprdy1729)
- **Source:** https://github.com/Sandeeprdy1729/claude-design-skill/tree/main/skills/mcp-deduplicator

## Install

```sh
agentstack add skill-sandeeprdy1729-claude-design-skill-mcp-deduplicator
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# MCP Tool Deduplicator

The MCP ecosystem has 2000+ servers. Users routinely install 3–6 per project, and
conceptually identical operations (create a task, search code, post a comment) exist
across GitHub, GitLab, Jira, Linear, Notion, and others under different names and
schemas. Without deduplication, Claude burns tokens at every turn evaluating 40–90
tools to decide between semantically equivalent ones — and sometimes picks the wrong
one.

This skill maps every available tool across all connected MCP servers, detects semantic
duplicates, and produces a unified abstraction layer with explicit routing rules so
Claude is presented with a clean, deduplicated toolset.

---

## SLASH COMMANDS

| Command | Action |
| --- | --- |
| `/scan` | Full scan of all connected MCP servers; output duplicate map |
| `/diff  ` | Compare two specific servers tool-by-tool |
| `/abstract ` | Show the canonical abstraction for a named operation (e.g. "create issue") |
| `/route ` | Given a natural language task, recommend the single best tool to use |
| `/matrix` | Print the full deduplication matrix (all servers × all canonical operations) |
| `/config` | Generate a `.mcp-dedup.yml` routing config ready to paste into your project |
| `/audit ` | List all tools from a single server with duplicate annotations |
| `/stats` | Summary: total tools, duplicate count, reduction %, canonical operations |
| `/simulate ` | Test the routing config by running a natural-language query through it — shows which tool wins |
| `/test-all` | Run 10 common operations through the routing layer; show tool resolution for each |
| `/verify` | After generating config, automatically run /simulate on 5 common queries to confirm routing works |

---

## HIGH-LEVEL WORKFLOW

```
Input: tool manifests from ≥2 MCP servers (or a list of server names)
    │
    ├─ Phase 1: Inventory
    │     Collect all tool names, descriptions, parameter schemas
    │
    ├─ Phase 2: Semantic Grouping
    │     Cluster tools by canonical operation category
    │
    ├─ Phase 3: Duplicate Detection
    │     Within each cluster, score pairs for semantic similarity
    │     Flag duplicates, near-duplicates, and functional equivalents
    │
    ├─ Phase 4: Canonical Selection
    │     For each duplicate group, select the preferred tool
    │     Apply selection criteria (schema richness, server priority, specificity)
    │
    ├─ Phase 5: Routing Layer
    │     Generate routing rules: canonical name → preferred tool + fallback
    │     Produce .mcp-dedup.yml config
    │
    └─ Phase 6: Validation
          Verify no canonical operation is left without a tool
          Flag any tool with no canonical match (unique capability — keep it)
```

---

## PHASE 1 — INVENTORY

For each connected MCP server, collect:

1. **Server name** (e.g. `github`, `gitlab`, `jira`, `linear`, `notion`, `slack`).
2. **Tool list** — name, description, and parameter schema for every tool.
3. **Server priority** — user-defined preference order. If not provided, ask:
   ```
   Which server is your primary for [code hosting / task management / docs]?
   This determines which tool wins when duplicates are found.
   ```

If the user cannot paste tool manifests directly, use the known tool lists for common
servers from the built-in registry (see Phase 2 — Standard Operation Taxonomy).

**Tool record format:**

```
server   : github
name     : create_issue
desc     : "Creates a new issue in the specified repository"
params   : { owner, repo, title, body, labels[], assignees[] }
category : [unresolved — assigned in Phase 2]
```

---

## PHASE 2 — SEMANTIC GROUPING

Assign each tool to one or more **canonical operation categories**. These are
server-agnostic operation names that represent what the tool does, not which server
it belongs to.

### Standard Operation Taxonomy

| Category | Canonical name | Example tools across servers |
| --- | --- | --- |
| **Issue management** | `issue.create` | `create_issue` (GitHub), `create_ticket` (Jira), `createIssue` (Linear) |
| | `issue.get` | `get_issue`, `fetch_ticket`, `get_issue_detail` |
| | `issue.list` | `list_issues`, `search_issues`, `get_issues` |
| | `issue.update` | `update_issue`, `edit_ticket`, `update_issue` |
| | `issue.comment` | `add_issue_comment`, `add_comment`, `create_comment` |
| | `issue.close` | `close_issue`, `resolve_ticket`, `complete_issue` |
| **Pull request / MR** | `pr.create` | `create_pull_request`, `create_merge_request` |
| | `pr.get` | `get_pull_request`, `get_merge_request` |
| | `pr.list` | `list_pull_requests`, `list_merge_requests` |
| | `pr.review` | `create_review`, `submit_review`, `approve_merge_request` |
| | `pr.merge` | `merge_pull_request`, `merge_merge_request` |
| | `pr.comment` | `add_pull_request_review_comment`, `add_comment_to_mr` |
| **Repository** | `repo.get` | `get_repository`, `get_repo`, `fetch_project` |
| | `repo.list` | `list_repositories`, `get_repos`, `search_projects` |
| | `repo.search` | `search_repositories`, `search_code` |
| | `repo.file` | `get_file_contents`, `get_file`, `fetch_file` |
| | `repo.push` | `push_files`, `create_or_update_file`, `commit_file` |
| **User** | `user.get` | `get_me`, `get_user`, `whoami` |
| | `user.search` | `search_users`, `find_user` |
| **Search (global)** | `search.code` | `search_code`, `search_repositories` |
| | `search.issues` | `search_issues`, `search_tickets` |
| **Notifications** | `notification.list` | `list_notifications`, `get_notifications` |
| | `notification.read` | `mark_notification_read`, `dismiss_notification` |
| **Documents / pages** | `doc.create` | `create_page` (Notion), `create_document` (Google) |
| | `doc.get` | `get_page`, `fetch_document` |
| | `doc.update` | `update_page`, `edit_document` |
| **Messaging** | `message.send` | `send_message` (Slack), `post_message` |
| | `message.list` | `list_messages`, `get_channel_history` |
| **Releases / tags** | `release.get` | `get_latest_release`, `get_release_by_tag` |
| | `release.list` | `list_releases`, `list_tags` |

Tools that do not match any standard category are tagged `UNIQUE` and always kept.

---

## PHASE 3 — DUPLICATE DETECTION

Within each canonical category, score every pair of tools for semantic similarity.

### Similarity Scoring

A tool pair is scored on four axes:

| Axis | Weight | Description |
| --- | --- | --- |
| **Name similarity** | 20% | Edit distance / token overlap between tool names |
| **Description similarity** | 40% | Semantic similarity of the description strings |
| **Parameter schema overlap** | 30% | Fraction of parameters that map to the same concept |
| **Category match** | 10% | Whether both tools were assigned the same canonical category |

**Composite score** = (name × 0.2) + (desc × 0.4) + (schema × 0.3) + (category × 0.1)

### Duplicate Thresholds

| Score | Classification | Action |
| --- | --- | --- |
| ≥90 | **Exact duplicate** | Keep one; suppress the other entirely |
| 70–89 | **Functional equivalent** | Keep one as canonical; expose the other only if server is specified |
| 50–69 | **Near-duplicate** | Keep both but add routing rules to disambiguate |
|  User: `/route create a task for the login bug and assign it to @maya`

```
ROUTE RECOMMENDATION
Query intent  : issue.create
Assignee hint : @maya (user lookup needed)
Platform hint : none detected

Recommended tool: github/create_issue
  Reason: github is the declared primary server for issue management.
  Params:  title="Login bug fix", body="…", assignees=["maya"]

Alternative (if user says "Jira" or provides a project key):
  jira/create_ticket
  Params:  summary="Login bug fix", description="…", assignee="maya"
```

### Example: `/matrix` excerpt

```
DEDUPLICATION MATRIX
                     github   gitlab   jira   linear
─────────────────────────────────────────────────────
issue.create           ●        ○        ↑       ✕
issue.comment          ●        ✕        ✕       –
pr.create              ●        ↑        –       –
pr.merge               ●        ✕        –       –
repo.file              ●        ✕        –       –
search.code            ●        ✕        –       –
sprint.board           –        –        ●       –
message.send           –        –        –       –

●  canonical  ○  demoted  ↑  override  ✕  suppressed  –  not available
```

---

## VERIFICATION AND ITERATION LOOP

After `/config` generates the routing config, do not stop. Automatically run `/verify`:

**`/verify` protocol:**

Run these 5 simulation queries through the generated config and show which tool each resolves to:

1. "Create a new issue about the login bug" → should resolve to `issue.create` canonical
2. "Comment on issue #42" → should resolve to `issue.comment` canonical
3. "Open a pull request for the auth branch" → should resolve to `pr.create` canonical
4. "Search the codebase for 'session timeout'" → should resolve to `search.code` canonical
5. "Get the contents of src/auth.ts" → should resolve to `repo.file` canonical

If any simulation resolves to a suppressed or wrong tool, flag it:

```
VERIFY RESULT
  ✓ issue.create  → github/create_issue
  ✓ issue.comment → github/add_issue_comment
  ✗ pr.create     → gitlab/create_merge_request  (WRONG — should be github/create_pull_request)
    Fix: add trigger "pull request" to github entry; current rule matches "merge request" first

  3/5 routing rules verified. 1 fix required before config is safe to deploy.
  Run /config after fixing to regenerate.
```

**Iteration after fix:**
1. User corrects the routing rule or server priority.
2. Re-run `/config` → `/verify`.
3. Repeat until all 5 simulations pass.
4. Then run `/stats` to confirm the final reduction number.

**Reduction goal:** A healthy deduplication should reduce exposed tools by ≥40%. If reduction is <40%, the server priority list is likely incomplete — ask the user to confirm their primary server for each category.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Sandeeprdy1729](https://github.com/Sandeeprdy1729)
- **Source:** [Sandeeprdy1729/claude-design-skill](https://github.com/Sandeeprdy1729/claude-design-skill)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-sandeeprdy1729-claude-design-skill-mcp-deduplicator
- Seller: https://agentstack.voostack.com/s/sandeeprdy1729
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.