{"version":"2.1.267","anchor":"tool-entry-dedup-logic-loosened-in-schema-change-tracking","canonical_anchor":"tool-entry-dedup-logic-loosened-in-schema-change-tracking","heading":"Tool-entry dedup logic loosened in schema-change tracking","tier":"internal","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267\/e\/tool-entry-dedup-logic-loosened-in-schema-change-tracking","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267","markdown":"### Tool-entry dedup logic loosened in schema-change tracking\n\nTool-entry dedup when tracking schema changes now only checks against already-kept entries, not a separate reference set\n\n**Unclear.** What visible effect this has for users, since the finding only describes the internal dedup condition, not its downstream consequence.\n\n**What**\n\nIn the internal logic that tracks which tool entries are kept, stripped, or removed when a tool's schema changes, an entry is no longer excluded from the \"kept\" list just because a tool of the same normalized name exists in a separate reference set. Now, an entry is only blocked from being added if it's already in the kept list itself.\n\n**Why**\n\nThis loosens the deduplication rule, which likely means fewer tool entries get incorrectly dropped from the kept list during schema-change tracking, though the finding doesn't specify the exact downstream effect.\n\n- Area: MCP\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}