Mcp Deduplicator

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
• Source: Sandeeprdy1729/claude-design-skill
• License: Apache-2.0

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