What can you do with this server?

This server provides an interactive panel inside Claude Desktop for managing MCP server configurations without manually editing the config file. * Opens an inline UI panel via the open-mcp-config-manager tool. * Reads the current Claude Desktop MCP config from the OS-appropriate path. * Displays each MCP server as an editable card (name, command, args, env). * Allows adding servers from templates (filesystem, github, sqlite, postgres, memory) or blank. * Saves changes with an atomic write and timestamped backup of the previous config. * Automatically quits and relaunches Claude Desktop after a successful save so new configs take effect. * Preserves non-mcpServers JSON keys verbatim. * Provides app-only tools (read/write/status/restart) invisible to the model, ensuring user-controlled edits. * Checks configured MCP servers via an MCP initialize handshake to see which ones respond. * Includes install/uninstall commands that safely register or remove the manager from claude_desktop_config.json.

How do I use claude-mcp-config-manager?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-mcp-config-manager Open the MCP config manager." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

claude-mcp-config-manager

by bkristesiashvili

Overview Schema Related Servers Score Discussions

Local

claude-mcp-config-manager

An MCP App you install into Claude Desktop that gives you an inline UI for editing claude_desktop_config.json — add, remove, and update MCP server entries without opening the file in a text editor.

What it does

One model-visible tool: open-mcp-config-manager — opens the panel.
The panel then:
- reads the current config (path resolved per-OS)
- shows each server as an editable card (name, command, args, env)
- lets you add servers from templates (filesystem, github, sqlite, postgres, memory) or blank
- saves back with an atomic write and a timestamped backup of the previous file
- Save & restart Claude — after a successful save it automatically quits and relaunches Claude Desktop so the new config takes effect
Non-mcpServers keys in the JSON are preserved verbatim.

Related MCP server: MCP Server Generator

Security notes

The model cannot see your existing server list, args, or env vars — the read/write/restart tools are marked visibility: ["app"], so only the UI (which you, the user, drive) can call them.
Every write is triggered by clicking Save & restart Claude in the panel. The model has no way to add a rogue MCP server behind your back, and no way to restart the app on its own.
Every save writes a claude_desktop_config.json.bak.<timestamp> next to the file first, so you can always roll back.

OS support

Works on macOS, Windows (installer and Microsoft Store builds), and Linux (community Claude Desktop builds; XDG_CONFIG_HOME is honored when set). The config path, the running-status check, and the save-and-restart flow each have per-OS implementations:

macOS — graceful osascript quit, force-kill of leftovers, relaunch via open -a Claude.
Windows — graceful window close then Stop-Process; relaunch via the Start Menu app alias (covers Store and installer builds), falling back to the exe that was running, then %LOCALAPPDATA%\AnthropicClaude\claude.exe.
Linux — remembers the running binary's path before killing so it can relaunch exactly what ran; falls back to claude-desktop / claude on PATH, then the desktop entry via gtk-launch.

Install into Claude Desktop

Requires Node.js 18+.

Automatic (recommended):

npx -y claude-mcp-config-manager install

or, if you prefer a global install, npm install -g claude-mcp-config-manager — its postinstall hook registers the app the same way.

Either way the app lands in claude_desktop_config.json as an npx -y entry (idempotent; existing servers and settings are preserved, a timestamped backup is kept, and a config file with invalid JSON is never touched). Restart Claude Desktop and say "Open the MCP config manager". On first use Claude Desktop asks once to allow the app's tools — that prompt is the host's own consent step and can't be pre-approved by an installer. install can be run again at any time, e.g. to re-add the app after an uninstall. Set MCP_CONFIG_MANAGER_NO_AUTOCONFIG=1 to npm install without touching the config.

A bare npx -y claude-mcp-config-manager (no install) is not a reliable way to register: npx runs the postinstall hook only the first time it fills its cache, shows none of its output, and on every later run just starts the server and waits on stdin.

Manual (alternative):

Add this to your claude_desktop_config.json yourself:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Windows (Microsoft Store install): %LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "config-manager": {
      "command": "npx",
      "args": ["-y", "claude-mcp-config-manager"]
    }
  }
}

(On Windows, use "command": "npx.cmd" if plain npx fails to spawn.)

Uninstall

npx -y claude-mcp-config-manager uninstall
npm uninstall -g claude-mcp-config-manager

The first command removes the app's entry from claude_desktop_config.json (every other server and setting is kept, a timestamped backup is written first, and a file with invalid JSON is never touched); restart Claude Desktop afterwards. The second removes the package (skip it if you never installed globally). The order doesn't matter — npx -y fetches the package again if it's already gone, which is also why removing the config entry is the step that actually matters: the npx -y entry keeps working without the global install. To put the app back later, run npx -y claude-mcp-config-manager install.

npm uninstall alone can't do this. npm 7 and later don't run a package's preuninstall/postuninstall scripts at all (by design — see "A Note on a lack of npm uninstall scripts" in npm's docs). On npm 6 the package's preuninstall hook runs the same cleanup automatically; MCP_CONFIG_MANAGER_NO_AUTOCONFIG=1 skips it there too.

Installed from source? node dist/server.js uninstall in the checkout also removes entries that point at that checkout's dist/server.js.

Build from source

npm install
npm run build

Produces:

dist-ui/mcp-app.html — the bundled single-file UI
dist/server.js — the compiled MCP server (stdio transport)

Point your config at it with "command": "node", "args": ["/absolute/path/to/dist/server.js"] — node dist/server.js install writes exactly that entry for you — or run npm install -g . and use the claude-mcp-config-manager command.

Restart Claude Desktop. Then, in a chat:

Open the MCP config manager.

Claude will call open-mcp-config-manager, the panel appears, edit, click Save & restart Claude. The config is written, then Claude Desktop quits and relaunches itself with the new servers loaded. Done.

The one caveat

Claude Desktop reads claude_desktop_config.json on startup, which is why the Save button restarts the app for you: a detached helper process (which survives the quit) closes Claude Desktop gracefully, force-kills any leftovers, and relaunches it — via the Store app alias or the installer exe on Windows, osascript/open -a on macOS. Your current chat reopens when the app comes back; unsaved panel edits do not.

The panel marks its own entry with a this app badge and disables its Delete button — removing it and saving would make the panel unavailable on the next launch. If you really want it gone, run claude-mcp-config-manager uninstall (see Uninstall); timestamped backups cover accidents either way.

Files

Path	What it does
`server.ts`	MCP server: opens panel + read/write tools
`mcp-app.html`	UI shell + styles (theme via host CSS variables)
`mcp-app.ts`	UI logic (uses `App` from `@modelcontextprotocol/ext-apps`)
`vite.config.ts`	Bundles the UI into one HTML file with inlined JS/CSS
`tsconfig.json`	Vite/UI TS config
`tsconfig.server.json`	Server TS config (compiles `server.ts` → `dist/server.js`)
`scripts/postinstall.mjs`	Registers the app in `claude_desktop_config.json` (`install` subcommand; npm `postinstall`)
`scripts/uninstall.mjs`	Removes it again (`uninstall` subcommand; npm 6 `preuninstall`)

Available Tools

5 tools

check-server-statusCheck MCP server statusA

Probe each configured MCP server with an MCP initialize handshake to see which ones actually respond (UI use only).

ParametersJSON Schema

Name	Required	Description	Default
`servers`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the operation's mechanism (initialize handshake) and its purpose (determining which servers respond), which is useful. However, it is silent on timeout/error handling, failure reporting, return format, and whether the probe has any side effects, leaving meaningful gaps for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence states the action, method, and outcome with no filler. The parenthetical 'UI use only' is an efficient usage restriction. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, but the description gives a reasonable summary: what it checks and what it reveals ('which ones actually respond'). Yet it omits details a caller would need, such as the shape of the result, behavior on non-responding or hanging servers, and the exact semantics of the servers parameter. It is adequate for a simple status probe but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only refers vaguely to 'configured MCP server' and does not explain the required key/command fields or the optional args/env properties within the servers array. The schema's property names are self-evident only to someone already familiar with MCP server configs, so the description fails to add the needed semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Probe') and resource ('each configured MCP server'), names the exact mechanism ('MCP initialize handshake'), and states the goal ('to see which ones actually respond'). This clearly distinguishes it from sibling tools like read-mcp-config and write-mcp-config, which deal with config file operations rather than live probing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly marks the tool as 'UI use only', which is a clear when-not-to-use restriction for an agent. It also makes the intended scenario obvious (checking server liveness), though it does not name specific sibling tools as alternatives or give conditions for choosing one over the other.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open-mcp-config-managerOpen MCP Config ManagerA

Open an interactive panel to view and edit Claude Desktop's MCP server configuration (add, remove, or update servers without editing claude_desktop_config.json by hand).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure. It discloses that the tool opens an interactive panel, involves viewing/editing config, and can add/remove/update servers, which signals user-in-the-loop and potential writes. It does not mention whether changes are applied immediately or require user confirmation, but for a launcher-style tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action ('Open an interactive panel') and packs the capabilities and advantage into a concise parenthetical. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema tool, the description covers the core action, resource, and effects. The only material gap is explicit usage rules versus sibling tools, which is already reflected in the usage_guidelines score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero properties, so there are no parameter semantics to clarify. The description's functional explanation is sufficient; no parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Open') and resource ('interactive panel... MCP server configuration'), and enumerates add/remove/update capabilities. This clearly distinguishes it from sibling tools like read-mcp-config or write-mcp-config, which operate directly on config data rather than launching an interactive panel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for interactive, user-driven configuration management ('interactive panel', 'without editing...by hand'), which contrasts with programmatic sibling tools. However, it never explicitly states when to choose this over read-mcp-config/write-mcp-config or that it is unsuitable for automated/headless use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read-mcp-configRead MCP configA

Read Claude Desktop's MCP config from disk (UI use only).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. The verb 'Read' and 'from disk' convey a non-mutating read operation, which is useful, but the description does not state what is returned (raw contents vs parsed config) or any error behavior. It is minimally transparent for a simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the core action and resource, and includes the key constraint without any padding. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool, the description covers the core function, but because there is no output schema, the return value is not described. The agent is left to infer whether the tool returns raw file text, parsed JSON, or a status object. This is a notable gap for a complete description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100% vacuously. Per the baseline for no parameters, the description does not need to add parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') with a clear resource ('Claude Desktop's MCP config') and source ('from disk'). It also adds a usage context ('UI use only') and is readily distinguishable from siblings like write-mcp-config and open-mcp-config-manager.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'UI use only' provides an explicit usage constraint, telling the agent this tool is intended for UI contexts. It does not explicitly name alternatives or exclusions, but the read vs. write split is implied strongly enough for a tool this simple.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

restart-claudeRestart Claude DesktopA

Quit and relaunch Claude Desktop so config changes take effect (UI use only).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It explicitly discloses that the tool quits and relaunches the application and notes UI-only usage, which is transparent about the side effect and intended scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that front-loads the action and reason. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output tool, the description fully covers what the tool does, why to use it, and a usage restriction (UI only). No schema or output needs to be described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so there is nothing to document. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (quit and relaunch) and resource (laude Desktop), plus the purpose (so config changes take effect). Clearly distinct from sibling tools that manage config files or server status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger: when config changes need to take effect. Does not explicitly name alternatives or exclusions, but the context is unambiguous given the sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write-mcp-configWrite MCP configA

Persist an MCP config to disk. Creates a timestamped backup of the previous file first.

ParametersJSON Schema

Name	Required	Description	Default
`config`	Yes

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing side effects. It meaningfully discloses that a timestamped backup of the previous file is created before writing, which is valuable behavioral context for a mutating disk operation. It does not detail the exact target path or overwrite semantics, but the backup behavior is a significant transparency improvement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the core purpose and then adding the key backup side effect. Every word contributes meaningful information with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write/config tool with no annotations and no output schema, the description is functional but leaves gaps: it does not specify where the config is stored, how overwrites interact with the backup, whether validation occurs, or whether a restart/refresh is needed after writing. These details would materially affect correct invocation, though the core write-plus-backup behavior is covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides no explanation of the 'config' parameter or its nested structure. The schema itself reveals property names and requirements, but the description does nothing to clarify the intended meaning, format, or relationship to mcpServers, leaving the parameter semantics under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action, 'Persist an MCP config to disk', identifying the resource and operation. It is distinguishable from read-mcp-config and open-mcp-config-manager by the write/persist framing, though it does not explicitly name a sibling or contrast itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this when you need to save an MCP configuration to disk. It provides no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as read-mcp-config or open-mcp-config-manager, leaving selection partially to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool maps to a clearly distinct action: interactive editing, reading config, writing config, checking server status, and restarting Claude. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow a consistent imperative verb-first pattern with hyphenated lowercase naming, such as read-mcp-config, write-mcp-config, and restart-claude. The naming is predictable and easy to scan.

Tool Count5/5

Five tools is well-scoped for a config management server. Each tool covers a necessary step in the config lifecycle without redundant additions.

Completeness5/5

The tool set covers the full workflow: read the current config, edit it interactively, persist changes with backups, verify server connectivity, and restart Claude to apply changes. No obvious dead ends or missing critical operations.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
Arlet
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1

Related MCP Servers

MCP Configuration Editor
Developer Tools File Systems App Automation
r3-yamauchi
A
license
A
quality
D
maintenance
Enables safe management of MCP server configuration files for AWS Q Developer and Claude Desktop, including adding, updating, removing servers, automatic backups, and validation.
Updated a year ago (2025-06-15 22:48 UTC)
7
MIT
MCP Server Generator
Developer Tools
SerhatUzbas
F
license
Not graded
quality
F
maintenance
Creates, manages, and registers custom MCP servers for Claude Desktop. Enables users to generate and configure new MCP servers through natural language.
Updated a year ago (2025-06-12 13:54 UTC)
11
mcp-serverman
Developer Tools Command Line
benhaotang
A
license
Not graded
quality
C
maintenance
Enables LLMs to manage MCP server configurations, including listing, enabling, disabling, and version control.
Updated 2 years ago (2025-02-24 14:55 UTC)
10
MIT
mcp-mode-switcher
Developer Tools App Automation
JasonBates
F
license
Not graded
quality
D
maintenance
An MCP server that lets you switch between different MCP configuration profiles directly from inside Claude Desktop.
Updated 8 months ago (2026-01-14 10:45 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bkristesiashvili/mcp-config-manager'

If you have feedback or need assistance with the MCP directory API, please join our Discord server