[FEATURE] Server-agnostic MCP tool references in subagent tools: (mcp__*__<tool> or a server-segment glob)

Status Open
Reported on v2.1.258
Maintainer reply None cached
Activity 1 comment · opened Sep 20, 2026

Problem

Subagent tools: frontmatter can only name an MCP tool by its full mcp__<server>__<tool> string, and the server segment is whatever the user (or claude.ai, or Claude Desktop) named the connection. A plugin that ships agents scoped to one vendor's MCP tools cannot know that name: on one machine the same backend is mounted as mcp__Kiteworks__… (local stdio, user-chosen name), mcp__claude_ai_Kiteworks_Content_MCP_…__… (claude.ai org connector, admin-chosen display name) and, in Claude Desktop, mcp__<connection-uuid>__… (#77598).

Tested on 2.1.258: mcp__*iteworks*__get_top_folders is reported "unrecognized"; mcp__*iteworks*__* and mcp__*iteworks* are "recognized but matched no tools"; matching is case-sensitive (mcp__kiteworks__* does not match a server named Kiteworks). So there is no portable way to write a plugin agent that is least-privilege on one MCP server.

Request

Support a server-agnostic tool reference in subagent tools: / disallowedTools: (and ideally permission rules), for example:

  • mcp__*__<tool> — the named tool from any server, or
  • mcp__*<substring>*__<tool> / glob in the server segment, case-insensitive.

Current workaround

Omit tools: (inherit everything), add a disallowedTools: denylist of built-ins, and ship a plugin-level PreToolUse hook that reads agent_type and tool_name from stdin and enforces a per-agent allowlist by bare tool name. It works, but it means every MCP call spawns a shell per installed plugin, and any hook failure is non-blocking (allow).

Environment: Claude Code 2.1.258, Windows 11; the wildcard results were identical for exec and headless runs.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗