{"version":"2.1.265","anchor":"built-in-tool-classification-gets-a-special-case-exception-f","canonical_anchor":"built-in-tool-classification-gets-a-special-case-exception-f","heading":"Built-in tool classification gets a special-case exception for one built-in name","tier":"internal","area":"Tooling Architecture","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/built-in-tool-classification-gets-a-special-case-exception-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Built-in tool classification gets a special-case exception for one built-in name\n\nOne built-in tool now gets a special-case exception in the built-in vs MCP classification logic\n\n**Unclear.** The finding doesn't say which specific tool this exception applies to.\n\n**What**\n\nThe internal logic that classifies a tool as MCP (Model Context Protocol), built-in, or undefined now takes an extra input and adds a special case: if a tool's name matches one particular built-in tool and none of the extra input matches a specific identifier, it's classified as \"built-in\" even in a situation where it would otherwise have failed the general built-in check.\n\n**Why**\n\nThis fixes a case where that particular tool could be misclassified, ensuring it's consistently recognized as a built-in tool.\n\n- Area: Tooling Architecture\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}