Regra de permissão do MCP fica mais estrita: mcp__a não cobre mais a__b

A v2.1.299 (14 de outubro) mudou como uma regra de permissão nomeando um servidor MCP é interpretada: mcp__a passou a valer só para o servidor chamado exatamente a, não mais para um servidor cujo nome comece com a__ (como a__b). Quem precisa cobrir todas as ferramentas de um servidor deve escrever a regra como mcp__<servidor>__*.

Antes da v2.1.299, uma regra de permissão escrita como mcp__a tinha um efeito colateral pouco óbvio: por causa de como o nome da ferramenta MCP é montado internamente (servidor e ferramenta concatenados com ), essa regra também acabava valendo para qualquer servidor cujo nome completo começasse com a — por exemplo, um servidor literalmente chamado a__b. A v2.1.299, de 14 de outubro, fechou essa brecha: a regra agora casa só com o servidor nomeado exatamente a. Para cobrir todas as ferramentas de um servidor de propósito, a forma correta passa a ser mcp____*.

É uma mudança de comportamento, não só uma correção cosmética: uma regra de deny ou allow escrita contando com o casamento por prefixo antigo pode parar de se aplicar onde antes se aplicava — silenciosamente, sem erro.

Por que importa

Quem tem regra de permissão própria em settings.json ou settings.local.json referenciando um servidor MCP deve reler essas regras depois de atualizar, principalmente se o nome de algum servidor MCP configurado contém __ ou é prefixo do nome de outro. Uma regra de allow que silenciosamente deixou de cobrir uma ferramenta pode virar prompt de permissão inesperado; uma de deny que deixou de cobrir pode ser pior ainda, numa configuração de segurança que você acreditava estar fechada.