Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Configurator Server show my current config"
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.
A Model Context Protocol (MCP) server that provides tools to manage, edit, backup, and validate Claude Desktop and other client JSON configurations.
This application is built with the official @modelcontextprotocol/sdk and zod for argument schema validation, enabling client LLMs (like Claude or ChatGPT) to programmatically read and modify their own configuration and environment setups.
mcp-configurator/
├── lib/
│ ├── backup.js # Handles backup creation, listing, and restores
│ ├── config.js # Handles JSON loading, syntax validation, and updates
│ ├── validator.js # Checks system path command executable existence
│ └── utils.js # Filepath resolvers and cross-platform defaults
├── backups/ # Stores configuration backup files (.bak)
├── package.json # Project metadata and dependencies (type: module)
├── server.js # Server entry point running StdioServerTransport
└── README.md # DocumentationRelated MCP server: Python MCP Custom Server
Install Dependencies: Open a terminal in the project directory and run:
npm installSince it uses Stdio transport, the server is meant to be spawned by an MCP host (such as Claude Desktop or Cursor). You can run it manually to check for syntax or launch issues:
npm startNote: This command will run and listen on stdin/stdout. You will see MCP Configurator server running on stdio outputted to stderr to avoid polluting the JSON-RPC channel.
To add this configurator server to Claude Desktop on Windows, open your %APPDATA%\Claude\claude_desktop_config.json and add the mcp-configurator to your mcpServers list:
{
"mcpServers": {
"mcp-configurator": {
"command": "node",
"args": [
"C:/Desktop/my workspace/work/server.js"
]
}
}
}Replace C:/Desktop/my workspace/work/server.js with the actual absolute path to where you saved this project.
For Cursor or VS Code, configure a new stdio-based MCP client with:
Command: node
Arguments: C:/Desktop/my workspace/work/server.js
The server registers the following tools:
get_configReads a configuration JSON file.
Input:
path (string, optional): Custom absolute path to the configuration JSON file. If omitted, defaults to the current system's Claude Desktop config file path.
Output:
The full JSON config payload.
save_configSaves configuration JSON after automatically creating a timestamped backup of the current state.
Input:
path (string, required): Absolute path to the file to overwrite.
config (object, required): The new JSON configuration object.
Output:
Success message with the name of the backup created.
list_backupsLists all available configuration backups under the backups/ workspace directory.
Input: None.
Output:
Formatted list of all files detailing filename, backup date, and file size.
restore_backupReverts the target configuration file using a selected backup file. Creates a new backup of the current state before overwriting as a safety measure.
Input:
filename (string, required): Filename of the backup (e.g. claude_desktop_config.json.bak-2026-07-08T11-04-05-123Z).
path (string, optional): Custom absolute path to restore into. Defaults to the active configuration path.
Output:
Confirmation message of successful restoration.
validate_commandSpawns standard shell diagnostic tools (where on Windows, which on macOS/Linux) or queries paths to confirm if an executable exists on the host machine. Helpful for verifying if custom MCP server commands (e.g. npx, python, git) are executable.
Input:
command (string, required): The executable binary name or absolute path to check.
Output:
JSON object indicating success status, resolved PATH location, and descriptive message.
Reads the Claude Desktop configuration file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional custom absolute path to the configuration JSON file. If omitted, resolves to the default Claude Desktop configuration path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Reads'. No details on safety, error handling when file is missing, permissions required, or return format. This is insufficient for an agent to understand behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the action. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is adequate but lacks output behavior. Since there is no output schema, the agent is left guessing what the tool returns. Adding the return type would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the optional path parameter. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reads the Claude Desktop configuration file', providing a specific verb and resource. This distinguishes it from sibling tools like save_config (write) and list_backups (backup operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context for when to choose get_config over siblings like validate_command or restore_backup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available configuration backups with filename, creation timestamp, and size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the output fields but fails to state that the operation is read-only, whether authentication is required, or any potential side effects. For a list operation, the description should at least imply safety (e.g., 'This operation does not modify any data').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, concise sentence that efficiently conveys the tool's purpose and output. Every word serves a purpose, and it is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no nested objects), the description is complete enough. It informs the agent about the returned fields (filename, timestamp, size) and the scope ('all available'). However, it could mention if backups are ordered or filtered, but that's not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema description coverage is 100% trivially. The baseline for 0 parameters is 4. The description does not need to add parameter information, and mentioning the output fields adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available configuration backups and includes the specific fields returned (filename, creation timestamp, size). The verb 'lists' and resource 'configuration backups' are unambiguous, and the tool is distinct from siblings like restore_backup or save_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus its siblings, nor does it provide exclusion criteria. The agent must infer that this is for listing backups based on context, but there is no direct guidance such as 'Use this to view backups; use restore_backup to restore them.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restores a selected backup configuration to the configuration file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional custom configuration file path to restore into. If omitted, uses the active config file. | |
| filename | Yes | Name of the backup file to restore. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only says 'restores' without clarifying if it overwrites, needs permissions, or whether unsaved changes are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with verb and object. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Description fails to specify result of restoration (e.g., config reloaded? requires restart?) or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restores'), the object ('backup configuration'), and the target ('configuration file'), distinguishing it from siblings like list_backups and get_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., save_config). No conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves the configuration JSON after automatically creating a timestamped backup.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the configuration file. | |
| config | Yes | The full JSON configuration object to save. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavior (automatic backup creation), which is critical for understanding the tool's side effects. However, it does not mention other important behaviors like overwriting existing files, error handling, or permission requirements. With no annotations, the description carries full burden and leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that front-loads the core action. Every word is necessary; no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema) and the presence of sibling tools that clarify the ecosystem, the description covers the essential purpose and key behavior. It could be slightly improved by noting the backup location or naming convention, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters ('path' and 'config'), so the schema already provides adequate meaning. The description adds no additional parameter-level detail beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Saves the configuration JSON') and explicitly mentions an important side-effect (automatic timestamped backup). This distinctly differentiates it from sibling tools like get_config (read), list_backups (list), restore_backup (restore), and validate_command (validate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for saving configuration, but does not explicitly state when to use it versus alternatives, nor does it provide any conditions or prerequisites. Usage context is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a command executable exists on the system path or as an absolute path.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Executable name (e.g. node, npx) or absolute path to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It states the check is for existence, but does not indicate the return format (e.g., boolean, status code), or what happens on success/failure. This is insufficient for an agent to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. However, it is very brief and could benefit from structured format, but it has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature and one parameter, the description omits critical details about the return value (e.g., boolean, error) and behavior. An agent cannot fully understand what to expect from the tool's output, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'command'. The tool description adds no new meaning beyond what the schema already provides ('Executable name ... or absolute path'). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks existence of a command executable on the system path or absolute path. This specific verb+resource distinguishes it from sibling tools like get_config and list_backups, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or when not to. No alternatives or exclusions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_configlist_backupsrestore_backupsave_configvalidate_commandScored across 5 tools
Each tool targets a distinct operation: reading config, listing backups, restoring, saving, and validating a command. No overlap in purpose.
All tool names follow a consistent snake_case verb_noun pattern (get_config, list_backups, restore_backup, save_config, validate_command).
5 tools is well-scoped for a configuration server, covering essential operations without excess or deficiency.
Core CRUD-like operations are present (read, save with backup, backup management, path validation). Missing a delete backup tool, but it's a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, validate, edit, export (markdown/svg/png/mermaid), and search JSON Canvas files.
Validate oh-my-posh configurations and segment snippets against the official schema.
Read and write your Fresh Jots notes from Claude, Cursor, and any MCP client.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
