Claude Code / Codex / Cursor / Hermes Agent: zero config, one shared MCP config and skill set

One environment variable, four clients, one silent miss

Last week I added an environment variable to one of my MCP servers — API_BASE, pointed at an internal host.

Added it in Claude Code. Worked. Added it in Cursor. Worked. The Codex copy I meant to come back to, then forgot.

Three days later I was calling that same server from Codex and it wouldn't connect. I spent a while on the network before I found it: not the network. That config file simply didn't have the line.

Three configs, two correct, one stale. You never catch this at the moment it happens. You catch it weeks later, from a different client, at the worst time.

A copied config is a config that will drift

The annoying part isn't typing the same thing three times. Typing is cheap.

The annoying part is that once the same config is copied into three places, it stops being the same config. You change something in A. B and C don't move. Six months on, "the same server" has three different sets of parameters across your clients, and nothing tells you which one is right.

This has nothing to do with token savings. It's the oldest rule in configuration management: one thing, one source. Three copies means three truths, each rotting on its own schedule.

My ~/.claude.json has 12 servers I wrote by hand: 1,388 characters of JSON. And that's one client.

Collapse it to one, then fan it out

I looked around for something that would keep my server list in a single place, and the one I kept is mcptoon — a 342KB command-line program that runs on the Python standard library alone, no third-party packages.

It does one core thing: holds the server list itself, as the only copy (imported once from Claude's file). After that, whatever needs it, mcptoon pushes it out.

One sync command later it reported 6 hosts updated, 42 server entries written, 0 errors.

The six: Claude Desktop, Cursor, Cline, Windsurf, VS Code Copilot, Claude Code, all at once. Cursor and Windsurf had no config file at all — it created them. It took 7 of the 12 servers from my claude.json, which was enough to fill all six; the other 5 were experiments I'd left disabled.

Here's the part that matters: those six clients now hold six projections of one thing, not six copies that can drift.

Skills work the same way

Tools are half of it. Skills are the other half.

My machine has 427 SKILL.md files, and they add up to 1,193,709 tokens of text. That's bigger than most context windows. (I counted that with tiktoken's cl100k_base — tiktoken is my measuring tool, not part of mcptoon.)

mcptoon indexes the catalog and writes a one-line pointer into each client's instruction file. That pointer sits in your context at 39 tokens. When the agent needs a skill, it looks the skill up instead of carrying all 427.

Skills are the same shape of problem: one source, many readers. One mcptoon sync handles tools and skills together.

Off-list agents are easier, not harder

Here's where I got it wrong at first.

mcptoon auto-handles a fixed list of 12 known clients, in two groups. One group is the MCP-mounting GUI clients — the six above. The other group is Codex, Gemini CLI, opencode and the like: it doesn't touch their MCP config, it only writes a one-line skill pointer into the instruction file they read every session.

So what about Hermes Agent or OpenClaw, which fall into neither group?

There's no config file to hand-edit. mcptoon is a plain CLI, and any agent that can run a shell can be pointed at it — one line, and it sees every tool and skill.

I tested that on Hermes: one hermes mcp add call pointing mcptoon at it, and the connection came back green. The agent gains 9 gateway tools, and the dozens of upstream tools are all reached through those 9, with no per-tool setup.

So "not on the list" doesn't mean "unsupported." The list is about who gets the config written for them. The CLI path is open to any agent that can run a shell.

Limits

• All numbers are measured on my Windows machine (mcptoon 0.8.14). Your machine and your version will differ.
• mcptoon only auto-handles 12 known clients. If yours isn't on the list, use the CLI path. Don't expect the file to be written for you.
• I did not test OpenClaw on this machine — only Hermes. Anything with a shell should work, but that one's on you to try.
• The 39 tokens is the standing pointer, not "all skills in 39 tokens." The full skill text stays on disk until it's needed.
• It rewrites the config files of the clients it knows. Back them up first, or use mcptoon off to pull it back out.
• If you only run one client, your config can't drift. Don't optimize for its own sake.

One more thing

The tool isn't mine. I've been running it a few weeks, and the server list now lives in exactly one place.

Has a client's config ever quietly drifted out of sync on you? How did you finally notice — and what broke first?