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
The ability to create custom modes is super powerful, but I'd like to limit the MCP servers available to a specific mode.
For example, I prefer to do my git operations myself (commit, open PRs, etc) for Plan/Build. But I do want to have a "Review" mode that will have access to Pull Request, team member, and Atlassian data. This is context only needed on the Review mode, and not Plan or Build mode.
I would imagine that the mode definition would be extended to support something like:
It would be up to the opencode configuration to define which mcp tools are available to the mode. It could get verbose, but an easy task for an llm model to update/customize if needed.
the thing is for the mcp server to actually be responsive it needs to always be enabled. it's really just the tools that need to be disabled - it's just unclear what the tool name is because we use some autogenerated internal one
i'm doing a pass on MCP soon and i'll make this more clear - it'll basically look something like adding mymcp_tool_name: false to the existing tools field
Reacted by Preston Libby, Jared, zolegus, Marek Pazik, Devon Fulcher, sroidl-airup, Niko E., Tyler Nieman, Fayçal Mitidji, Thiago Lucio and 2 more
Composite key enable/disable like you're going to implement is great to prevent specific functionality from the agent.
The idea of disabling of the entire MCP server was to save on context window usage. My understanding is the entire list of tools for all MCP servers is provided to Claude on every request and those tokens count against input tokens usage. Minor issue for those on your recommended Claude Max/Pro plan
And not to throw another wrench in the mix, but perhaps users should also be able to set MCP tool permissions per-agent.
In my description, I was using "modes" to determine what type of agent is running. Is that not how modes are meant to be used? Sincerely, I am concerned I'm missing out on some workflow efficiency...
In my description, I was using "modes" to determine what type of agent is running.
@jaredbarranco Sorry, I should've been more clear. (And, TBH, I think there are too many abstractions in OpenCode and similar tools right now, so confusion like this is bound to increase!)
But when I said "agent" I was referring to the recently-introduced sub-agent functionality. I think sub-agents are (in theory) a better, more composable abstraction and I'd be happy to ditch modes in favor of sub-agents only.
@mybuddymichael I hadn't checked doc updates in a week... Completely missed the addition of sub agents until Aug 1st. I'm definitely going to migrate my "multi-mode" strategy to sub agents.
Composite key enable/disable like you're going to implement is great to prevent specific functionality from the agent.
The idea of disabling of the entire MCP server was to save on context window usage. My understanding is the entire list of tools for all MCP servers is provided to Claude on every request and those tokens count against input tokens usage. Minor issue for those on your recommended Claude Max/Pro plan
I've experienced this in Claude Code Max and it is a significant issue. I didn't realise until I ran Claude with --verbose and saw just how much context was being added to each agent, subagent, and worst of all, parallel agents!
I added all of the Cloudflare MCP agents and sending a simple 'hello' message to Claude would result in over 50% context usage. Running a few subagents in parallel meant that I was churning out 150K tokens/minute. Within a few minutes I had used 4M cached tokens and blasted my 5 hour rate limit!
To add on support for this, managing tool, consumption of context by scoping to agents is a pretty important feature that is not currently well supported in either Claude code or OpenCode that would be a killer feature.
To illustrate the point, a fresh session in Claude code can consume 26.6% before you even begin conversing with the LLM due to all the included tool context if not managed well.
Being able to defer the tool context cost to the agent's own context window where the tool is actually used, and not consume the main session context just to make the tool available to the agent would be a really nice win for context management.
Being able to defer the tool context cost to the agent's own context window where the tool is actually used, and not consume the main session context just to make the tool available to the agent would be a really nice win for context management.
@rekram1-node In Claude code and OpenCode agents operate with their own independent context window, separate from the main session context. They can leverage the same tools, such as MCP servers, that are available from the main session and report back their results once the agent finishes its task. The current limitation with the agent implementation is that tools must be made available in the main session to be available to the agent, which consumes the main session context, even if it delegates the tool work down to the agent. The request is to allow the agent to load tools independently of the main session and take the context hit for the tool, not the main session.
That's interesting, then OpenCode agents definitely operate differently from Claude code agents. The tool descriptions for MCP always get included in Claude code, as there's no way to disable them in config like there is in OpenCode. Didn't realize an agent config could override a parent config explicit tool disable.
Activity
thdxr commentedon Jul 17, 2025
the thing is for the mcp server to actually be responsive it needs to always be enabled. it's really just the tools that need to be disabled - it's just unclear what the tool name is because we use some autogenerated internal one
i'm doing a pass on MCP soon and i'll make this more clear - it'll basically look something like adding
mymcp_tool_name: falseto the existingtoolsfieldjaredbarranco commentedon Jul 17, 2025
Composite key enable/disable like you're going to implement is great to prevent specific functionality from the agent.
The idea of disabling of the entire MCP server was to save on context window usage. My understanding is the entire list of tools for all MCP servers is provided to Claude on every request and those tokens count against input tokens usage. Minor issue for those on your recommended Claude Max/Pro plan
mpazik commentedon Jul 20, 2025
Could there be a way to disable it by provider?
Like
"github/*": falseAnother question is whether tools should be enabled or disabled by default.
In my workflow, I would prefer to always explictly enable them.
Perhaps the wildcard concept could be expanded to
"opencode/*": falsefor default tools"mcp/*": falsefor all mcp.nefthy commentedon Jul 26, 2025
@thdxr I believe it would be good to have a way to list all the tools so it is easier to figure out the config.
mybuddymichael commentedon Jul 28, 2025
And not to throw another wrench in the mix, but perhaps users should also be able to set MCP tool permissions per-agent.
jaredbarranco commentedon Jul 29, 2025
In my description, I was using "modes" to determine what type of agent is running. Is that not how modes are meant to be used? Sincerely, I am concerned I'm missing out on some workflow efficiency...
mybuddymichael commentedon Jul 29, 2025
@jaredbarranco Sorry, I should've been more clear. (And, TBH, I think there are too many abstractions in OpenCode and similar tools right now, so confusion like this is bound to increase!)
But when I said "agent" I was referring to the recently-introduced sub-agent functionality. I think sub-agents are (in theory) a better, more composable abstraction and I'd be happy to ditch modes in favor of sub-agents only.
jaredbarranco commentedon Aug 3, 2025
@mybuddymichael I hadn't checked doc updates in a week... Completely missed the addition of sub agents until Aug 1st. I'm definitely going to migrate my "multi-mode" strategy to sub agents.
thiagodebastos commentedon Aug 11, 2025
I've experienced this in Claude Code Max and it is a significant issue. I didn't realise until I ran Claude with
--verboseand saw just how much context was being added to each agent, subagent, and worst of all, parallel agents!I added all of the Cloudflare MCP agents and sending a simple 'hello' message to Claude would result in over 50% context usage. Running a few subagents in parallel meant that I was churning out 150K tokens/minute. Within a few minutes I had used 4M cached tokens and blasted my 5 hour rate limit!
thoughtentity commentedon Aug 22, 2025
To add on support for this, managing tool, consumption of context by scoping to agents is a pretty important feature that is not currently well supported in either Claude code or OpenCode that would be a killer feature.
To illustrate the point, a fresh session in Claude code can consume 26.6% before you even begin conversing with the LLM due to all the included tool context if not managed well.
Being able to defer the tool context cost to the agent's own context window where the tool is actually used, and not consume the main session context just to make the tool available to the agent would be a really nice win for context management.
rekram1-node commentedon Aug 22, 2025
@thoughtentity
can you elaborate on:
thoughtentity commentedon Aug 22, 2025
@rekram1-node In Claude code and OpenCode agents operate with their own independent context window, separate from the main session context. They can leverage the same tools, such as MCP servers, that are available from the main session and report back their results once the agent finishes its task. The current limitation with the agent implementation is that tools must be made available in the main session to be available to the agent, which consumes the main session context, even if it delegates the tool work down to the agent. The request is to allow the agent to load tools independently of the main session and take the context hit for the tool, not the main session.
rekram1-node commentedon Aug 22, 2025
@thoughtentity unless I misunderstand you I think you may be mistaken:
{ "$schema": "https://opencode.ai/config.json", "agent": { "research": { "description": "use anytime I ask you to research something", "tools": { "context7*": true } } }, "tools": { "context7*": false } }Here my main agent can't use any context7 tools, but my research agent can
rekram1-node commentedon Aug 22, 2025
Main agent never sees the tool data, it only sees output from research agent.
Ex:
https://opencode.ai/s/ayzq1Egj
thoughtentity commentedon Aug 22, 2025
That's interesting, then OpenCode agents definitely operate differently from Claude code agents. The tool descriptions for MCP always get included in Claude code, as there's no way to disable them in config like there is in OpenCode. Didn't realize an agent config could override a parent config explicit tool disable.
rekram1-node commentedon Aug 22, 2025
Yeah as opencode matures I imagine there will be more branching off, core team is super focused on best DX and they are very opinionated.
Going to close out this issue since it is complete