Claude Code, Cursor, and Gemini CLI Walk Into a Bar — Their MCP Configs Don't Talk to Each Other

Last week I spent 40 minutes debugging why my database MCP server worked in Cursor but silently failed in Claude Code. Same project. Same machine. Different config files, different env var resolution, different behavior. That's when I realized: I'm maintaining three separate MCP setups and none of them know about each other. ## How I Got Here My current stack is Claude Code for heavy refactoring and architecture work, Cursor for day-to-day editing and quick fixes, and Gemini CLI when I want a second opinion on something or need to run a task in a separate context. Each one has legitimately different strengths and I'm not giving any of them up. But somewhere along the way, my MCP configuration situation became genuinely embarrassing. For Claude Code, I've got a `~/.claude/claude_desktop_config.json` with my MCP servers. For Cursor, there's a `.cursor/mcp.json` in my home directory. Gemini CLI has its own setup. When I add a new MCP server — say, a Postgres tool or a Slack integration — I'm doing it in three places. When I update a server path or an environment variable, I'm doing it in three places. When something breaks, I'm debugging three different config formats to find which one has the stale entry. And they don't stay in sync. They never stay in sync. ## The Specific Pain Points **The duplication problem** is the obvious one. I counted recently: I have 6 MCP servers configured. That's 6 entries in Claude Code's config, 6 entries in Cursor's config, and fragments of them scattered elsewhere. Every time I add a server it goes in twice minimum. **The environment variable problem** is worse. Claude Code and Cursor handle env var resolution slightly differently. A server that reads `DATABASE_URL` from the environment works fine in one and quietly gets `undefined` in the other. You find out when you're mid-session and the AI starts making stuff up because the tool just returned nothing. **The path problem** comes up when you have MCP servers that are locally-built scripts. I've got a custom file-indexing server I wrote. Its path is absolute, hardcoded in three config files. When I reorganize my dev folder structure — which I do every few months — I'm hunting down stale paths across every tool. **The Skills problem** is the one nobody talks about. Claude Code has a Skills Hub where you can define reusable slash commands and workflows. These don't exist in Cursor at all. So I build up a useful `/review-pr` skill in Claude Code and then forget it exists when I'm working in Cursor. The institutional knowledge lives in one tool and doesn't cross over. ## What I Tried First I tried symlinking the config files. Doesn't work — the formats are different enough that a config valid for Claude Code breaks Cursor's parser. I tried a shell script that generates all the configs from a single source of truth YAML file. This worked okay for about two weeks until the formats diverged again and I had to debug why my script was generating invalid JSON for one of the tools. I tried just... accepting it and manually keeping them in sync. This is what most people do. It's not sustainable. ## The Unified Gateway Approach What I actually wanted was something that sits between my AI tools and my MCP servers — a single place to register, manage, and expose servers that any tool can connect to. This is what [Mantra](https://mantra.gonewx.com?utm_source=devto&utm_medium=article&utm_campaign=devto-article-launch)'s MCP Unified Gateway does. Instead of each tool getting its own config, you register your MCP servers once in Mantra, and all your tools connect to it as a single endpoint. Claude Code points to it. Cursor points to it. Gemini CLI points to it. The gateway handles the rest. The practical result: I add a new MCP server once. I update a server path once. I change an environment variable once. All three tools see the change immediately without touching their individual configs. The Skills Hub piece is separate but related — it's where you define reusable workflows and commands that are stored in Mantra rather than in any one tool. When I build a `/review-pr` flow now, it's accessible from whatever tool I happen to be in. ## The Security Angle I Wasn't Expecting to Care About When I started consolidating everything into one place, I also had to think harder about what was in those configs. MCP server configurations often contain API keys, database connection strings, and service tokens. I had these scattered across three config files in plaintext. Mantra has a local Rust engine that scans sessions for credentials — API keys, passwords, connection strings — and flags them for redaction. I hadn't thought about this as a feature I needed until I actually looked at what was sitting in my config files and session logs. The one-click redaction workflow is useful enough that I now run it as a matter of course before sharing any session output. ## What the Workflow Looks Like Now Day-to-day, the mental model is simpler: 1. Add or update an MCP server in Mantra once 2. All tools pick it up automatically 3. Skills are defined once, usable anywhere 4. Session recordings are git-anchored so I can go back to any point in a working session if something goes sideways That last part — session replay anchored to git states — is what makes it feel like a real safety net. I can work aggressively, try things, jump between tools, and know that if a session goes wrong I can rewind to the exact commit and context where everything was working. ## Who This Is For If you're only using one AI coding tool consistently, the MCP config problem doesn't hit you as hard. The duplication is annoying but manageable. But if you're running Claude Code and Cursor together — and a lot of developers are, because they genuinely have different strengths — the config drift becomes a real tax on your time. I was losing 20-30 minutes a week to sync issues, debugging, and hunting down stale config entries. That adds up. Mantra supports Claude Code, Cursor, Gemini CLI, and Codex. If you're in the multi-tool camp and the config chaos resonates, it's worth checking out: [https://mantra.gonewx.com?utm_source=devto&utm_medium=article&utm_campaign=devto-article-launch](https://mantra.gonewx.com?utm_source=devto&utm_medium=article&utm_campaign=devto-article-launch) --- *The MCP ecosystem is still young enough that every tool has done their own thing with configuration. That's fine for now. But the more seriously you use these tools, the more the lack of coordination between them starts to cost you real time.*