[FEATURE] Scope .claude/rules/*.md to a tool name / MCP server, not just file paths

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet. I checked #8288, #374, #6010, #24054, #14320, and #51274 — all address MCP server access/visibility/permissions scoping, not the rules/memory system's own conditional-loading keys.
• [x] This is a single feature request

Problem Statement

.claude/rules/*.md files support exactly one conditional-loading mechanism: paths frontmatter, which per the docs triggers "when Claude reads files matching the pattern, not on every tool use." This works well for rules about a codebase's file types, but there's no equivalent for rules that are about a tool or MCP server's behavior rather than a file's.

Concretely: I maintain rules documenting gotchas for a Google Workspace MCP server (an npm-packaged wrapper around a Google Workspace CLI) — things like a hard 100,000-character output-truncation cap, a curated-subset-of-the-real-API limitation, and safety rules for a Gmail tool (never call a send-capable command). This content is relevant every time the corresponding MCP tool is called (a Docs batchUpdate call, a Gmail draft-creation call, etc.) — including in a purely conversational session where no file is ever read or edited (e.g. "read my 5 most recent Gmail messages"). Because paths only fires on file reads, a rule scoped that way silently never loads in exactly the sessions where it matters most.

The only current workaround is making the rule unconditional (dropping paths entirely), so it's always in context. That works, but it defeats the purpose of conditional rules — every MCP integration's gotchas end up permanently resident in every session's context, even sessions that never touch that integration. That's the same context-bloat problem paths was built to solve for file-type-specific rules, just unsolved for tool-specific ones.

Proposed Solution

Add a second, parallel frontmatter key — e.g. tools — that accepts tool-name patterns (reusing the same matcher syntax already used by hook matcher fields, e.g. mcp__google-workspace__*, Bash, mcp__slack__*) and triggers a rule's loading whenever Claude is about to call a matching tool, the same way paths triggers on a matching file read. A rule could specify paths, tools, or both.

Example:

---
tools:
  - "mcp__google-workspace__gmail_*"
---

Alternative Solutions

• Skills: semantically triggered from the prompt, so in principle this content could live in a skill instead. But skills are shaped for multi-step procedures, not standing facts/constraints — putting a flat "never do X" safety rule into a skill's relevance-triggered activation model is an awkward fit, and it changes the content's shareability/precedence semantics versus a rule.
• PreToolUse hooks: can match on tool name and intervene, but hooks are a shell-script enforcement layer, not a way to add markdown guidance into context — much heavier machinery than "surface background knowledge for this integration."
• Unconditional rule (current workaround): works today, but scales badly — the more MCP integrations documented this way, the larger the permanently-resident rule set grows, with no way to load integration-specific knowledge only when that integration is actually in play.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. I have a rule file documenting Gmail-safety rules (never issue a send-capable call, prefer a specific draft-creation tool, always attach a real signature) for a Gmail MCP integration. It's currently unconditional because there's no other option.
2. I ask Claude, in a plain conversational session with no files open, to "list my 5 most recent Gmail messages."
3. Because this is a pure MCP tool-calling session, paths scoping is unusable — the rule has to be unconditional to ever apply here.
4. With tools scoping, I could instead write a rule scoped to mcp__google-workspace__gmail_*, and it would load exactly when a matching Gmail tool is about to be called — not before, and not for unrelated sessions that never touch Gmail.

Additional Context

• Confirmed via the official docs that paths is file-read-only: "Path-scoped rules trigger when Claude reads files matching the pattern, not on every tool use." (https://code.claude.com/docs/en/memory#path-specific-rules)
• Hook matcher fields already establish a precedent for glob/exact tool-name matching syntax inside Claude Code (e.g. PreToolUse matchers) — reusing that syntax for a rules tools key would keep the two mechanisms consistent.
• Searched existing MCP-related issues (#8288, #374, #6010, #24054, #14320, #51274) — all are about MCP server visibility or access scoping (subagents, mcp list output, permission wildcards), not about the rules/memory system's own conditional-loading keys.