Just add the MCP server, then ask the agent to read context. By default it will pull in everything in your project. For a large code base you will need a big context window (hello 2.5 max?) or you can pull in specific components.
No more creating duplicate files / functions because the agent doesn’t know they exist, or hopelessly failing at a task because it working in the dark.
This is dramatically faster and more predictable/consistent than the agent reading individual files in chunks. The whole thing is a single tool call.
Screenshot of using it to get a meaningful overview that actually looks at all the code:
BTW: Cursor can silently drop context that is larger than the allowed maximum, so if you have a sizable project and the agent acts like the tool call never happened try reducing what you are bringing in (“read context for xyz”)
Cursor will still summarize or drop on long conversations, but often that’s OK once the model works out what it needs to do. And with the tool it’s easy to add whatever you need in again.
Just fixed a bug that might have stopped this working for .dotdirs like .cursor - you can reload the server or restart cursor to have the latest version
I strongly disagree context is overrated. Especially with Gemini 2.5 having much better context capabilities, even <100K.
Have you ever tried to get cursor to review even a moderately sized codebase? I mean actually do it, not make educated guesses based on listing some directories and peeking at a few files.
If you use AI coding as a scalpel then you don’t need context, that’s true. Personally I prefer to use it as a team member and that requires some understanding of the project.
If repomix can do this too, great - doesnt hurt to have more than one tool available.
Well, maybe not generically overrated as its a good feature when requiring lot of context and not much thought, but I’m seeing too much posts about context being so good when in reality it dilutes intelligence, don’t believe Google marketing, they were saying Gemini 2.0 was 99% efficient on context(…)
Wouldn’t it be better for your Persona(team member) to have a readme.md or similar inside each of your directories, with a brief explanation and a diagram to explain states and flows, than to get all the raw code? Then you could build a Persona mdc file that calls your tool to retrieve that context or to have a diversity of behaviors depending on your needs
For big codebases some kind of summarization and/or RAG strategy is necessary. But why do that if everything you need easily fits into context? Summarizing is limited, error-prone, and requires manual work or automation to keep it in sync. If it gets out sync it can be actively harmful.
What I have found useful is an automated memory bank approach recording design decisions (e.g. Roo Memory Bank / Roo Flow does this). That is complementary to the code as it records intent and serves as an aid to understanding for both human and AI.
I’m sold on the context capabilities of 2.5 from personal experience. It also does exceptionally well in a good third party assessment (real ICL and reasoning, not needle-in-haystack): Fiction.live
Don’t get me wrong, it’s still better to constrain context to what you need. But default cursor agent behavior is to pull in much less than what is required to do even a moderately holistic task. This is a solution for that problem.
And there is a definite cost in time and effort in tightly managing context vs. simply pulling in XYZ component and being done with it.
I would highly recommend that people avoid dumping the entire codebase into context. Flooding the context window with everything makes it harder for the AI to find the relevant information. The signal gets lost in the noise, increasing the chance of hallucinations or the AI overlooking the critical pieces it actually needs. Larger context != smarter context. You’re adding more hay to the haystack while trying to find the needle.
You wouldn’t give a surgeon every patient file for a single operation; you give them the specific patient’s chart. Similarly, the AI needs targeted information relevant to the task, not the entire codebase history and dependencies. Overloading it is inefficient and prone to errors.
This approach of dumping the entire codebase into context is a band-aid for:
* Poor Prompt Engineering: Vague requests like “read context” are ineffective. You need to guide the AI.
* Weak Software Design: If the AI constantly misses things, it might indicate low cohesion, poor modularity, or inconsistent naming conventions in the codebase itself, making things hard to find even for an AI.
A More Effective (and Scalable) Approach:
Precision Prompting: Be specific. Tell the AI what task to perform, why, and point it to the most relevant starting points (files, functions, classes). Take a little extra time in your prompts to explain the concept in detail. Maybe even use the Ask or Chat mode to refine your prompt to be more targeted to what you want. I know that some people don’t want to spend this much time, but you’re already saving over 100x by not writing or iterating on the code yourself. You can afford to take a few extra minutes to refine your prompts.
Strategic Context: Instead of raw code dumps, provide:
Key code snippets (using @) relevant to the current task.
A “rules” or “guidelines” file outlining project standards, constraints, or architectural patterns the AI must follow. This should include rules on ensuring that functions and classes are single-purpose and limited in scope. This makes it easier for the AI to iterate and solve bugs. Humans too!
Iterative Guidance: Treat the AI like a pair programmer. Give it focused tasks, review the output, provide feedback, and point it towards the next relevant pieces of information. This is where being a good software engineer comes into play and why vibe-coding has proven to cause major problems for non-technical individuals.
Forcing massive context is a shortcut that encourages lazy prompting and ignores fundamental software principles. Focus on providing high-quality, targeted context and clear instructions along with a rule file, which will yield far better, more reliable results and encourage better development practices overall.
What you say about performance decaying rapidly certainly used to be true but that is objectively not a concern with Gemini 2.5 <100K - Fiction.live.
Even for Sonnet 3.7 I have had much better results giving the model and entire codebase than relying on the agent deciding what to read for holistic prompts.
Can you do better if you have cleanly modular code and @include exactly what the model needs to know? Absolutely. But that takes a significant amount of time, especially as you can’t seem to copy-paste a list of @includes into cursor chat and have the UI recognize them.
If the codebase is module (mine is), personally I would much rather just say “read context for the abc module” and be done with it than messing around with listing individual files, maintaining summaries, etc.
Good points, and just to clarify, I wasn’t suggesting manually @-mentioning every single file is the way to go. Dumping the entire codebase only seems practical for genuinely small projects (maybe <100k tokens). Including a relevant folder can absolutely make sense if many of its files are needed.
My main caution is: if you find yourself needing to include a large number of files (say, a dozen or more) for one task, it might be a flag that the task itself is too broadly scoped. Asking the AI to bite off too much at once is often where code quality degrades very quickly, especially in a “vibe coding” context where structure can easily get lost. Overly broad tasks tend to produce lower-quality code, regardless of context size – a risk amplified when “vibe coding” without clear constraints. Breaking the problem into smaller, more focused requests for the AI is much more effective.
Remember, just because the code looks good, doesn’t mean it’s scalable and performant. I don’t know your engineering level, but I’m trying to keep in mind that a large chunk of Cursor’s userbase is non-technical engineers who have fully embodied the dunning-kruger effect and make mistakes by trying to include the entire codebase or making their prompts much too broad.
For use on a pre-existing code base with a sizable team I agree with your view - the tool should be a scalpel, not a substitute for a developer.
Personally I have a fair amount of experience including working on one of the largest FANG codebases. But I am interested in pushing AI coding to the limit on smaller projects where rapid development is the priority. I wouldn’t call this vibe coding as I do understand the codebase and manage what the model is doing. The idea is to use the AI as a team member and delegate tasks at a high level - but not blindly.
Gemini 2.5 is exciting because it is the first model with the intelligence and context handling to really succeed at this.
And in practice I can successfully do this with Roo and Gemini 2.5. Cursor is very bad at it unless going to significant lengths to provide the required context, e.g. with this tool.
Good discussion here. I am finding the context limitations are forcing me to be a better disciplined programmer, KYC, Know Your Code.
I have had to become intellectually more committed to my codebase design where its apparent these broad context limitations exist.
Having to work smarter to stay on top of the AI limitations has made me a better programmer. The people doing all the complaining … don’t get any sympathy from me.
