Hello everyone,
Yes, I created the post back then, including Version 1. To this day, it has primarily not been changed, which is very frustrating.
It is simply incredibly limiting that Cursor has control over all orchestration-related topics and that this cannot be configured. It is fine to work this way if there is an option to disable it.
For over a year, or perhaps even longer, all MCP-related items have simply been written into external files. This creates an endless loop: if you have your own MCP tools for reading files, you get stuck in that loop and have to rely on Cursor’s Read File tool to read the files. However, this means relying on Cursor’s orchestration layer, which again has limitations in how files are read.
For example, Read File has an internal limitation where, beyond a certain line length, it does not begin reading the entire file. This is naturally why you have your own MCP tools: to bypass Cursor’s orchestration layer and its tools, because sometimes you simply need to read large files.
As a result, you are stuck in an endless loop of Cursor limitations and the outsourcing of external files that cannot be bypassed. In some cases, this can partially be worked around through prompts, but that also does not work because system prompts are limited. You therefore remain stuck in an endless loop of limitations.
This has been a problem for an incredibly long time. Honestly, I also do not understand why these issues cannot be handled more transparently and why there cannot simply be an option to disable them. I created this post such a long time ago, and we are still stuck in this endless loop of limitations.
I have been working with Cursor for what feels like three years now, and I have noticed that the platform is increasingly moving toward vibe coding. Rather than making things more transparent, it seems to be trying more and more to complete tasks autonomously and present them in a more compact way.
Cursor is still clearly the number-one option among IDEs, without question. However, if this development continues, it will become increasingly frustrating to work with the tool from an enterprise-grade perspective. It is moving toward vibe coding and autonomous, asynchronous agent workflows instead of enabling developers to work closely with the IDE and configure everything themselves.
It must be ensured that these tools can primarily be disabled in some form—from system prompts and orchestration layers to all tools, limits, and the various options that are already set in one way or another. Users must be able to configure them themselves.
If we do not take this path, Cursor itself will inevitably become increasingly unusable. At the end of the day, developers at every level use it, from private use cases to highly scaled enterprise environments. The fact that tool configuration cannot be adjusted is already ridiculous.
