You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
--allowedTools does not keep unlisted MCP tools out of the model context #1899
--allowedTools only controls which tools Claude may run. Every tool exposed by an MCP server passed with --mcp-config is still sent to the model with every request, unless that tool is listed in --disallowedTools.
A workflow that adds a large MCP server (e.g. the GitHub MCP server) to use only one or two of its tools therefore pays for every other tool definition on every turn, often thousands of input tokens per request. To avoid that today, you have to:
find the full tool list of every server (e.g. from the system/init event of a run),
copy every tool you don't use into --disallowedTools, and
keep that list current whenever a server adds tools.
#533 reports the same thing from the user side ("they also seem to utilize a ton of tokens").
Proposal
An opt-in input, e.g. disallow_unlisted_mcp_tools: "true". Before Claude starts, the action connects to each --mcp-config server that --allowedTools names only some tools of, calls tools/list, and appends the server's other tools to --disallowedTools.
Servers allowed as a whole (mcp__server, mcp__server__*) and servers not named in --allowedTools are left alone.
Wildcard entries (mcp__server__get_*) keep every tool they match.
A server that can't be reached is skipped with a warning, so the run behaves as it does today.
It is opt-in because a disallowed tool can't be used even under bypassPermissions, so turning it on by default would change behavior for existing workflows.
I have a working implementation and can open a PR.
Activity
ranyhb commentedon Oct 14, 2026
@ashwin-ant