# How to Get the Complete Server Configuration Using the `get_config` Tool in DesktopCommanderMCP

> Discover how to get the complete server configuration using the get_config tool in DesktopCommanderMCP. Learn about blocked commands, feature flags, and system diagnostics.

- Repository: [Eduard Ruzga/DesktopCommanderMCP](https://github.com/wonderwhy-er/DesktopCommanderMCP)
- Tags: how-to-guide
- Published: 2026-08-05

---

**The `get_config` tool returns the complete DesktopCommanderMCP server configuration—including blocked commands, allowed directories, feature flags, and system diagnostics—by calling `await configManager.getConfig()` and enriching it with runtime context.**

The DesktopCommanderMCP server exposes a read-only tool named **`get_config`** that provides a comprehensive view of the server's runtime state. This tool is essential for debugging, auditing security policies, or verifying that your MCP client is operating with the expected constraints. In this guide, you'll learn how to invoke `get_config` from multiple contexts, understand its response structure, and interpret the configuration data it returns.

## How the `get_config` Tool Works

The tool implementation follows a clear three-step pipeline in [`src/tools/config.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/tools/config.ts).

### 1. Load the In-Memory Configuration

The **ConfigManager** singleton ([`src/config-manager.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/config-manager.ts)) maintains the authoritative server configuration. When `get_config` is invoked, it calls:

```typescript
const config = await configManager.getConfig();

```

This method (lines 236-244 in [`src/config-manager.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/config-manager.ts)) returns the cached configuration object, which includes settings loaded from the JSON configuration file and any runtime overrides.

### 2. Collect Runtime Context

The tool enriches the base configuration with additional runtime data:

- **Current client**: The `currentClient` export from [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) identifies which MCP client is connected
- **Feature flags**: State from [`src/utils/feature-flags.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/utils/feature-flags.ts) indicates which experimental capabilities are enabled
- **System information**: Data from [`src/utils/system-info.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/utils/system-info.ts) covers OS, CPU, memory, and environment details

### 3. Assemble the Structured Response

The final response (lines 90-141 in [`src/tools/config.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/tools/config.ts)) contains:

- A **plain-text summary** for human readability
- **`structuredContent.config`**: The complete configuration object for programmatic consumption
- **`uiHints`**: Auxiliary data like `availableShells` from `detectAvailableShells()`
- **`entries`**: An editable metadata list showing which fields can be modified via `set_config_value`

## Tool Registration and Schema

The `get_config` tool is registered in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) (approximately lines 1308-1333) with a description stating it returns the "complete configuration as JSON."

The argument schema in [`src/tools/schemas.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/tools/schemas.ts) defines `GetConfigArgsSchema` with a single optional parameter:

```typescript
// src/tools/schemas.ts#L4-L8
{
  origin: z.enum(["ui", "llm"]).optional()
    .describe("Origin of the request (UI widget or LLM)")
}

```

No arguments are required—`origin` simply helps the server distinguish between UI widget and LLM callers for logging purposes.

## Calling `get_config` from Different Clients

### MCP/JSON-RPC (LLM or Programmatic Client)

Send a standard MCP tool call:

```json
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "toolName": "get_config",
    "arguments": {}
  },
  "id": 1
}

```

The server responds with:

```json
{
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current configuration:\n{ ...full JSON shown here... }"
      }
    ],
    "structuredContent": {
      "config": {
        "blockedCommands": ["rm", "format"],
        "defaultShell": "/bin/bash",
        "allowedDirectories": ["/home/user/projects"],
        "telemetryEnabled": true
      },
      "uiHints": {
        "availableShells": ["/bin/bash", "/bin/zsh", "powershell.exe"]
      },
      "entries": [
        {
          "key": "blockedCommands",
          "value": ["rm", "format"],
          "valueType": "array",
          "editable": true
        },
        {
          "key": "telemetryEnabled",
          "value": true,
          "valueType": "boolean",
          "editable": true
        }
      ]
    }
  },
  "id": 1
}

```

**Key fields in `structuredContent.config`:**
- **`blockedCommands`**: Array of command names disallowed for security
- **`defaultShell`**: The shell used for command execution
- **`allowedDirectories`**: Paths outside which file operations are restricted
- **`telemetryEnabled`**: Whether usage analytics are collected

### Built-In Config Editor UI

Open the **Config Editor** resource at URI `config-editor://` in the DesktopCommanderMCP interface. The UI automatically invokes `get_config` with `origin: "ui"` and renders the structured response in an editable form. No manual arguments are needed.

### Direct HTTP/JSON-RPC (CLI or External Tools)

If the server is running locally, use `curl`:

```bash
curl -s http://localhost:9797 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/call","params":{"toolName":"get_config","arguments":{}},"id":1}' | jq .

```

Replace `9797` with your configured port if overridden in [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json).

## Understanding the Response Structure

| Response Section | Purpose | Source |
|------------------|---------|--------|
| `content[0].text` | Human-readable configuration dump | Assembled in [`src/tools/config.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/tools/config.ts) |
| `structuredContent.config` | Machine-parseable complete configuration | `configManager.getConfig()` + runtime context |
| `structuredContent.uiHints` | Auxiliary UI data (available shells, memory usage) | `detectAvailableShells()`, `process.memoryUsage()` |
| `structuredContent.entries` | Metadata for editable fields | Derived from schema definitions |

The `entries` array is particularly useful for UI builders: it indicates which configuration keys support modification via the companion `set_config_value` tool.

## Security and Safety Considerations

- **`get_config` is read-only**: The tool does not modify state, making it safe to invoke from untrusted contexts
- **No sensitive values exposed**: Passwords, tokens, and private keys are never included in the standard configuration response
- **Telemetry respect**: The `telemetryEnabled` field reflects the user's explicit privacy preference stored in [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json)

## Summary

- Invoke **`get_config`** with empty arguments or optional `origin: "ui"|"llm"` to retrieve the complete DesktopCommanderMCP configuration
- The tool aggregates data from **`configManager.getConfig()`**, **`currentClient`**, **feature flags**, and **system info** utilities
- Responses include both **human-readable text** and **`structuredContent.config`** for programmatic use
- Access the same data through **MCP JSON-RPC**, the **Config Editor UI**, or **direct HTTP** to localhost

## Frequently Asked Questions

### What configuration fields does `get_config` return?

The tool returns all server configuration fields including `blockedCommands`, `allowedDirectories`, `defaultShell`, `telemetryEnabled`, `maxCommandTimeout`, `logLevel`, and `featureFlags`. It also appends runtime-derived data such as `availableShells`, `memoryUsage`, `currentClient`, and system information (OS, CPU, Node version).

### Is `get_config` safe to call repeatedly?

Yes. According to the DesktopCommanderMCP source code, `get_config` is a pure read operation that does not modify state, log excessively, or trigger side effects. The underlying `configManager.getConfig()` method returns cached in-memory data with minimal overhead.

### Why does the response include both `text` and `structuredContent`?

The `text` field serves LLM clients that consume human-readable output, while `structuredContent.config` provides typed, parseable data for programmatic callers and UI widgets. This dual format ensures compatibility across all MCP client types without requiring multiple tool variants.

### How do I modify configuration values after viewing them?

Use the companion **`set_config_value`** tool, also implemented in [`src/tools/config.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/tools/config.ts). The `entries` array in `get_config` responses marks which fields are editable (`"editable": true`). Changes persist via `configManager` back to the JSON configuration file.