Repository navigation
Dart MCP server commands that modify files on disk can conflict with unsaved files #5785
Description
Some of the MCP server commands modify files on disk directly, so if there are unsaved changes you can result in conflicts when trying to save:
We previously excluded the run_tests tool in the MCP server (#5639) because VS Code contributes a version that works better inside the editor. I wonder if we should do something similar here:
- Identify any commands that might modify directly on disk
- Ensure Dart-Code (or VS Code) exposes the equivalent command directly
- Hide the MCP version of the tool
We should try to avoid duplicating functionality that we don't already have and is in the MCP server, but for things like format where we already have implementations but they're just not exposed to the model, maybe it makes sense to just expose them?
We'd need to review the full set and agree which this makes sense for.
WDYT @jakemac53?
Activity
DanTup commentedon Nov 11, 2025
I was going to expose the equivalents of format + fix all before excluding these, but I'm now thinking maybe we should just exclude them without.
For formatting, VS Code is already considering running save-participants on generated code (microsoft/vscode#254679), and doing so in a way that they can accept further edits without having to keep giving the formatted result back to the model. Users that want formatting likely already have format-on-save enabled.
And for "fix all", while we do have a command for this (although it's the entire workspace and not just a project), I'm not so sure this is something user are likely to delegate to AI (or that the model is likely to blindly just run this instead of fixing individually issues in the code). If we do think it's useful, maybe we should reopen and implement #5034
@jakemac53 interested in your thoughts - do you have any idea how often these are used?
jakemac53 commentedon Nov 11, 2025
In general if your model is editing the same files you have open in your IDE, you definitely don't want to be editing those files at the same time. This problem exists regardless of format on save, or a format tool being ran by the agent.
One possible option here would be for the agent to not be interacting with the disk directly at all (and maybe copilot functions in this way) - but have it instead use Editor APIs to view and edit the in memory representations of files?
We have a separate but related issue of the
analyzetool operating on the on-disk versions of files, where the editor spawned analysis server is actually running on the in memory versions of files. We need to try and share these analysis server instances probably.This sounds like it would be great for Copilot but it won't help any other agents.
Fwiw, I have long wished for a "fix all" type option in the IDE as opposed to manually applying each quick fix myself, that gets super cumbersome sometimes and I end up going to the CLI to run
dart fix.Regarding usage by AI agents this primarily comes down to prompting. If you tell the agent to format and fix files after editing them, they will pretty reliably do so. But they will rarely use these tools unless told to.
Regarding total usage of tools "analyze" is by far the most heavily used, followed by "run tests" and "format" which are roughly tied and closely followed up by "hot reload". Combined those tools are around 70% or so of all tool calls. The "dart fix" tool is quite far behind those, around 20% as much usage as "format", behind even tools like "pub" and "pub dev search".
DanTup commentedon Nov 11, 2025
Yep, VS Code provides tools for file reading and writing which the models will use (whenever a file is modified, I think it also force-saves it to reduce the chance of these kinds of issues if it decides to use terminal commands - but it doesn't save any files you've modified yourself).
The agent client protocol also has standards for file system access, but weirdly it seems like there is nothing for MCP. Maybe some of these aren't the right kind of tasks to do inside the MCP server 🤔
In VS Code we're already excluding that tool, because VS Code contributes a tool that lets the model read diagnostics already (and I haven't been through the logs, but some of the behaviour I've seen makes me wonder if it's also injecting text to alert the model diagnostics produced after it makes edits).
I haven't looked into the APIs, but I would hope that this is usable be other agents - at least those that choose to use the VS Code APIs. Those that don't use the VS Code APIs probably also won't be getting the tools from VS Code, so wouldn't be affected if we excluded this tool here.
That said, contributing a format tool from Dart-Code to replace the MCP one would not be difficult, so maybe we should do this if we want to exclude the MCP one.
If you're in VS Code, we already have this :-)
It's only for the entire workspace though (all open folders), and not scoped to a specific package/workspace folder. We could expose this (to replace the MCP one), but it's not like-for-like. If we think it would be better to allow only fixing a specific project/folder then maybe we should do that work before excluding the MCP one.
Thanks, that's useful to know!
jakemac53 commentedon Nov 11, 2025
That makes it even more interesting that it is consistently our highest used tool, crazy.
Never heard of this protocol, it seems similar to what Gemini CLI does with its IDE companion extension. Until VsCode supports it though I think its largely irrelevant as a protocol? Although, you can probably bolt support on the side via an extension (similar to the GCLI IDE companion).
It isn't clear how this should work with MCP though, although you could plumb support through, so that if an MCP server supported this protocol, the client could support forwarding the calls. This could be interesting in terms of allowing remote MCP servers to actually edit your local code (which might be a bad idea, but so are most LLM things...).
Oh nice, I just didn't know it existed, thanks :).
You could expose this directly to copilot certainly, and replace ours, if it would work better with VsCode. I think having it run on the whole workspace is fine.
I don't know of any other agents actually using the VsCode APIs today - although I expect them to eventually.
It seems reasonable to me to do this, if it will significantly improve the experience. While tool names generally are not supposed to be directly relied upon, you aren't provided a better way to exclude them which we are aware of and do generally avoid renaming tools as a result.
DanTup commentedon Nov 11, 2025
Yeah, I was surprised when you said that - although Cursor won't have this exclusion (we only include it in the registration through the VS Code API), I'm not sure if that's where most of your users are (I also know if/how you are detecting the IDE).
Gemini CLI actually implements ACP (it might have been the first? to work with Zed?) - https://zed.dev/acp/agent/gemini-cli
It definitely will mean more if VS Code does it. There is an open request for it. I saw GitHub seem to be embracing other agents (see https://github.blog/news-insights/company-news/welcome-home-agents/), so hopefully VS Code will too!
Oh, I didn't mean it should work with MCP, just that this solves a similar problem there. I'm surprised I couldn't find much about this kind of problem in MCP. Having tools that modify files on disk doesn't seem that crazy 🙃
Yeah, maybe this is the right thing - we already have it, and as long as we describe it well it can be up to the model. I'll do some testing of this - we can always iterate based on feedback.
So, going back on my suggestion above of just excluding them and not replacing them, I think I will try exposing these two commands before excluding the MCP ones, and we'll see how it goes :)
FMorschel commentedon Nov 11, 2025
Completely a guess here, but I'd say this will probably be mostly from CLIs. Since they keep working for a few iterations now, each step they do, they might be analysing the code to see if they made any mistakes. Then, after a simple change, they call it again.
jakemac53 commentedon Nov 11, 2025
Hah! Maybe the IDE companion stuff is actually implementing ACP and I just didn't realize.
Copilot operates similarly to all these CLI agents though. Really anything that supports MCP is probably going to be an "agentic loop" type client, certainly for development tools especially. The "chat" modes where applicable typically do not include MCP servers as an example.
Replace MCP server format/fix with IDE-friendly versions