Module 16 · Lesson 02

Claude Desktop MCP Configuration for Client Agents

Reading time: 20 minutes Track: Yungsten Tech Employee Curriculum · Engineer path

Why Claude Desktop is Yungsten's delivery vehicle

Claude Desktop is the right delivery mechanism for named agents in most Yungsten engagements. It runs locally on the client's machine, connects to their existing tools via MCP, doesn't require the client to manage infrastructure, and gives them a conversational interface their team can learn without a software engineering background.

The alternative — building custom agent UIs — is appropriate for specific situations but creates ongoing maintenance burden. Claude Desktop shifts that maintenance to Anthropic. We focus on configuration and knowledge, not app maintenance.

Claude Desktop installation for clients

Installation steps (for client machines):

1. Download Claude Desktop from claude.ai/download
2. Sign in with the client's Anthropic account (Teams or Enterprise)
3. Verify the installation opens and shows the standard Claude interface
4. Open Settings → Developer → Enable MCP servers

Pre-flight check before adding MCP servers:

• Client is on a paid plan (MCP requires Pro/Teams)
• Client's data classification allows the data sources you're connecting
• You've documented which MCP servers are being added and why

MCP server configuration

MCP servers are configured in Claude Desktop's claude_desktop_config.json. Location:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Basic structure:

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "@package/mcp-server-name"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Restart Claude Desktop after any config change.

Common MCP servers for client engagements

File system access (local documents):

"filesystem": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/client/documents"]
}

Useful for: clients who store documents locally or in a mounted network drive.

Obsidian/local markdown:

"obsidian": {
  "command": "npx",
  "args": ["-y", "mcp-obsidian", "/path/to/vault"]
}

Useful for: giving agents access to the client's Yungsten wiki.

Google Drive:

"gdrive": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-gdrive"],
  "env": { "GDRIVE_CLIENT_ID": "...", "GDRIVE_CLIENT_SECRET": "..." }
}

Custom internal API: For clients with existing internal APIs, you'll often build a thin MCP server wrapper. See the MCP SDK quickstart for Node.js (5-minute setup for a basic read-only endpoint).

Secrets management for client credentials

Never store production credentials in the config file directly if clients manage their own machines. Options:

• Environment variables: Set credentials at the OS level, reference as "env": { "KEY": "${ENV_VAR_NAME}" }
• macOS Keychain: For macOS clients, sensitive credentials can be retrieved from Keychain via a wrapper script
• Client's existing secrets manager: If they have AWS SSM, HashiCorp Vault, etc. — use it

Document exactly where credentials are stored, who manages them, and the rotation process. This is part of the handoff.

Testing the MCP configuration

After configuration, verify each server works:

1. Restart Claude Desktop
2. Open a new conversation
3. Type: "What MCP tools do you have available?" — Claude will list connected servers
4. Test each server: "List the files in [directory]" / "Search for [document] in the vault"
5. Document any failures before the client is watching

The most common failure: typos in the config JSON. Validate with a JSON linter before restarting.