Blog Logo

My MCP Setup for Coding with AI (the ones nobody tells you about)

My MCP Setup for Coding with AI

You’ve probably been there: you ask your AI to implement a feature, it starts writing code, seems to get everything right, and then suddenly… it uses an API that no longer exists. Or it does something completely different from what you had in mind. Or it starts repeating the same questions you already answered five messages ago.

Why does this happen? Simple: the AI is flying blind. It doesn’t know how your project is structured. It doesn’t know what you’ve decided to use and what you haven’t. It doesn’t know that library changed its API in version 4. You know it, but it doesn’t.

And there’s a fix. In fact, there are several. In this post, I’ll show you the tools and MCPs I use to give the AI all that context from the start - so the result is much, much better.


Plan before you code: Spec-Kit + Grill-with-Docs

The first one isn’t an MCP, but it comes before everything else. The problem with vibe coding - that “come on, build me a task management app” approach - is that the AI improvises. And it improvises well, but it has no idea about your constraints, your architecture decisions, or the stack you want to use. In the end, you spend all your time correcting it.

The solution is called Spec-Kit, from GitHub. It has over 114,000 stars, so it’s not exactly underground, but many people still don’t use it because they don’t fully understand what it is.

Spec-Kit gives you a structured workflow so you and the AI are always on the same page. You install it with one command, initialize your project, and you get a set of slash commands or skills depending on the agent you use.

The flow looks like this:

  1. You create a constitution: a file with the non-negotiable rules of your project - stack, code standards, whatever you need.
  2. You use /speckit.specify to describe what you want to build.
  3. You use /speckit.plan for the technical plan.
  4. You use /speckit.tasks to break it down into tasks.
  5. Once everything is validated, /speckit.implement lets the AI start implementing.

The difference from just prompting directly is huge. The AI doesn’t make things up - it executes a specification you’ve reviewed. It’s the serious answer to vibe coding.

And this pairs perfectly with Spec-Kit: Grill-with-Docs, by Matt Pocock. This isn’t a tool you install - it’s a skill, a technique. The idea is that before writing a single line of specification, the AI interviews you about your project. It asks questions so you both define the language of the project together - what a “user” is, what a “session” is, what “publish” means in your specific context. And as you go, it builds a CONTEXT.md file with all that shared vocabulary.

Why does that matter? Because from that moment on, the AI doesn’t have to reinvent concepts every time. It knows exactly what you’re talking about. And the code it generates will reflect that terminology precisely. If you search for “pitches” in your codebase, everything related shows up. No ambiguity, no guessing.

My recommendation: start with Grill-with-Docs to define the language and domain, then Spec-Kit for the development flow. They go hand in hand.


Give it context about your code: CocoIndex-Code and CodeGraph

Now we have planning. Next problem: the AI doesn’t know your codebase either. When you ask it to change something, it has to read file by file, run greps, search around… and that burns through tokens and takes forever.

There are two tools that solve this. They’re similar but not the same, so I’ll tell you about both and you pick the one that fits best.

The first is CocoIndex-Code. It’s a semantic code search engine based on AST - that is, on your code’s syntax tree, not just plain text. You install it in a minute, zero configuration, and it works as an MCP or skill in your agent. It indexes your project and lets the AI find code by concept, not exact name. For example: “where is user authentication handled?” And it finds it. Their own benchmarks claim a 70% token savings. And it’s completely local, no external services.

The second is CodeGraph. This one goes a step further: it builds a knowledge graph of your code. It doesn’t just search - it understands relationships. Which functions call this other function? What gets affected if I change this? Its benchmarks with Claude Code are pretty wild: 94% fewer tool calls and 77% faster code exploration. Also 100% local, uses SQLite. You install it with npx and configure the MCP in Claude Code.

So, which one should you use?

  • If your project isn’t huge and you want something that just works from minute one → CocoIndex-Code.
  • If you have a large project with tons of dependencies between modules and you want the AI to understand the impact of every change → CodeGraph.

It doesn’t make much sense to run both at the same time. Pick one.


Up-to-date library docs: Context7

Third problem: the AI uses the version of the library it saw during training. And that can be a year old or more. Has it generated code with an API that no longer exists? That’s exactly this.

Context7 solves this very elegantly. It’s an MCP that, when you ask something about a library, fetches the official up-to-date documentation and injects it directly into the AI’s context. Just add “use context7” to your prompt, and it gets the docs for the right version.

Install it with npx ctx7 setup, authenticate via OAuth, and you’re done. It has a free tier that’s more than enough for personal use.


Manage your repo without leaving the editor: GitHub MCP

This one is already better known, but I include it because I use it daily and it’s a game changer. The official GitHub MCP lets you manage your entire repository from Claude Code without opening a browser. Create issues, review PRs, check Actions status, make commits… all via natural language from the terminal.

The best part is that it has a remote endpoint ready to go, so you don’t need to install anything locally. OAuth and done. And since it’s official from GitHub, it’s well maintained and kept up to date.


Browser automation: Playwright MCP

To close the main section, the Playwright MCP from Microsoft. If you’ve ever wanted the AI to interact with a real browser - navigate a website, fill out a form, check that your app works - this is what you need.

The interesting thing is that it doesn’t use screenshots. It works with accessibility snapshots, meaning it reads the page structure the same way a screen reader would. It’s much more token-efficient and more robust than image-based solutions.

It’s perfect for end-to-end testing, automating repetitive web tasks, or reliable scraping.


Bonus 1: Oh My OpenAgent (for OpenCode users)

First bonus, and first an important clarification: this tool is not for Claude Code. It’s for OpenCode, another terminal coding agent and Claude Code’s direct competitor. If you don’t know what OpenCode is, I explain it in another video, but basically it’s the same idea - model agnostic, so you can use Claude, GPT, Gemini…

If you use OpenCode, there’s Oh My OpenAgent. It’s a plugin that completely transforms the experience: it adds specialized agents working in parallel, AST-level refactoring tools, automatic work loops… it’s like turning OpenCode into an entire team of AIs. It has over 62,000 stars on GitHub, so it’s no joke.

And here’s the key detail: Oh My OpenAgent already includes Context7 internally. So if you use this plugin, you don’t need to install Context7 separately. It’s already integrated.


Bonus 2: Coolify MCP (if you run your own server)

The second bonus is for those of you with a Coolify server. Coolify, in case you don’t know, is an open-source self-hosting platform - like Heroku, but yours, on your VPS. I have a video on the channel about it.

There’s a Coolify MCP, and although it’s not an official project, it’s very well maintained. It has 42 tools to manage your entire server: deploy applications, manage databases, view logs, handle projects… all from Claude Code, via natural language. If you already use Coolify, just install it.


Summary: my step-by-step setup

Here’s a quick recap of what you’re getting:

For whatWhat I use
Planning and specifyingSpec-Kit + Grill-with-Docs
Code contextCocoIndex-Code or CodeGraph
Up-to-date library docsContext7
Repo managementGitHub MCP
Browser automationPlaywright MCP
If you use OpenCodeOh My OpenAgent
If you use CoolifyCoolify MCP

One thing to watch out for: don’t install everything at once. With more than five or six active MCPs, the agent starts getting confused choosing tools. Start with the ones that fit your daily workflow and add from there.


Conclusion

The AI doesn’t have to work blind. With the right MCP setup, you can give it the context it needs to stop improvising and start executing against clear specifications, indexed code, and up-to-date documentation.

It’s not about having more tools - it’s about having the ones you actually use. Start with one or two, integrate them into your flow, and scale from there. The difference in the quality of the code the AI generates is massive.

If you made it this far and found it useful, share the post with someone fighting with AI every day. And if you have a tool I didn’t mention, drop it in the video comments - I’m genuinely interested.


References


What do you think?

Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .

Back to blog