mcpfoldManaging MCP servers by hand vs mcpfold
Editing each client’s MCP config by hand is perfectly reasonable for a single tool, but mcpfold pays off as soon as you run more than one MCP client: you keep one canonical config and fold it out to all of them, with secrets kept as references instead of pasted into files.
| By hand | mcpfold | |
|---|---|---|
| Source of truth | A separate config file per client | One canonical mcp.config.jsonc |
| Adding a server | Edit each client’s file yourself | mcpfold add, then sync to every client |
| Secrets | Pasted into each client’s config file | ${env:…} / ${op:…} references resolved at fold time |
| Keeping clients in sync | Copy changes between files by hand | One mcpfold sync |
| Curating tools per server | Hand-edit each client’s JSON | Allow / deny-list tools per server |
| Runs where | In each client | Locally, as a CLI |
| Cost | Free | Free, MIT-licensed CLI |
If you only use one MCP client, editing its config directly is a fine choice — there is nothing to fold out, and no tool to add. The case for mcpfold grows with each additional client you keep in sync.
mcpfold is a local-first CLI. It adds one tool to install and learn, in exchange for removing the per-client copy-paste and keeping secrets out of config files. Everything it does happens on your own machine.
mcpfold is deliberately not a hosted service or an enterprise gateway: there is no server-side access control, org audit, or hosted MCP servers. If you opt into the optional cloud for sharing config across a team, only the config with secret references is ever synced — never the secret values themselves.
Related
mcpfold is an independent, open-source project and is not affiliated with or endorsed by the MCP project or any other tool named here. Comparisons describe categories factually.