MCP is great, but it adds a lot of extra latency. The MCP servers themselves will stuff your context full of tool details, taking up valuable tokens that could be spent on code context. Then at runtime the LLM has to decide to call a tool, the tool call has to come back to your machine, the data is gathered and sent back to the LLM, then the LLM can act on that data. Multiply this by however many rounds of tool use the LLM decides it needs prior to taking action. If you are lucky the LLM will do a single round of parallel tool use, but not always.

The advantage of something more purpose built for gathering context from the IDE is that you can skip a lot of roundtrips. Knowing the user's intent upfront, the IDE can gather all the necessary context data preemptively, filter it down to a token efficient representation of just the relevant stuff, add it in the context preemptively along with the user's prompt, and there is a single trip to the LLM before the LLM gets to work.

But yeah I agree with your point about CLI capabilities for running in parallel, integrating in other places. There is totally room for both, I just think that when it comes to authoring code in the flow, the IDE approach feels a bit smoother to me.

I feel what you say is true only for auto-complete, which is no longer the ideal workflow for agentic coding. Otherwise the IDE doesn't know what it should include or not in the context, and you need an AI model to determine that.

What people do to avoid what you discussed, is multi-agents. The main agent can build up context, plan, than delegate execution to other agents, etc.

In my opinion, the benefit of the IDE is really just in the possibility of an improved UI/UX over a TUI.

It’s so much easier for me to prompt by:

- cmd-t fuzzy finding files of cmd-p finding symbols to open the various files that are relevant

- selecting a few lines in each file using fast IDE shortcuts to move and add

- drag and drop an image or other json files into prompt

- not leave the editor im already working on

Not to mention:

- viewing the agents edits as a diff in the editor and all the benefits of easily switching between tabs and one click rejecting parts etc

- seeing the sidebar of the agents thoughts and progress async alongside the code as I keep looking at things

- pausing the agent and reversing back steps visually with the sidebar

- not having to reconfig or setup my entire dev environment for some CLI - for example the biome v2 lsp just works since it’s already working in code which has the best support for these things

And really the list of reasons an editor is far better just never ends. Claude is ok, but I’m way way faster with Cursor when I do need AI.

To each their own, and I absolutely agree with the prior poster about both existing making a lot of sense. It comes down to personal preference. I just wanted to point out the CLI has no less support for feature and context, just a different UX to them.

The next level of features I want from Claude Code is LSPs built right into it, rather that something I have to configure with some random MCP server I download from some random place.