Feature Request: Support macOS Keychain as alternative to plaintext token in config

[smartwatermelon]

Summary

The current configuration requires OP_SERVICE_ACCOUNT_TOKEN to be stored as a plaintext value in the MCP config file (e.g., claude_desktop_config.json). This works well, but it means a sensitive credential lives in a predictable, human-readable location on disk. I'd love to see an alternative that lets users store the token in macOS Keychain and have the server read it at startup.

Context

I've been using this MCP server with Claude Desktop and have been very happy with it — it cleanly solves the problem of getting secrets into Claude's context without maintaining plaintext credential files. The Keychain concern came up as part of a broader audit of how credentials flow through my local AI tooling.

The specific issue: claude_desktop_config.json ends up containing the service account token in plaintext in an env block. Any process with filesystem read access — including Claude itself via the filesystem MCP — can read it. It also means the token appears in plaintext if someone accidentally commits the file.

Workaround I'm Currently Using

I solved this with a small launcher script that reads the token from Keychain and passes it to the MCP server via the process environment, keeping the config file free of any sensitive values:

~/.local/bin/1password-mcp-launcher.sh:

#!/usr/bin/env bash
set -euo pipefail

_token="$(security find-generic-password \
  -a "$USER" \
  -s "op-service-account-claude-automation" \
  -w 2>/dev/null)" || {
  echo "ERROR: 1Password service account token not found in Keychain." >&2
  exit 1
}
export OP_SERVICE_ACCOUNT_TOKEN="${_token}"
unset _token
exec npx -y @takescake/1password-mcp "$@"

claude_desktop_config.json:

"1password": {
  "command": "/Users/yourname/.local/bin/1password-mcp-launcher.sh",
  "args": []
}

This works well — the config file contains no sensitive values, and the script fetches the token from Keychain at startup. I'm documenting this pattern as the recommended approach for anyone concerned about the token-in-config issue.

Feature Request

It would be nice if the server supported Keychain lookup natively so that users wouldn't need the launcher indirection. A possible approach:

"1password": {
  "command": "npx",
  "args": ["-y", "@takescake/1password-mcp"],
  "env": {
    "OP_KEYCHAIN_SERVICE": "op-service-account-claude-automation",
    "OP_KEYCHAIN_ACCOUNT": "myusername"
  }
}

If OP_SERVICE_ACCOUNT_TOKEN is not set but OP_KEYCHAIN_SERVICE is, the server would read the token from Keychain at startup. The existing OP_SERVICE_ACCOUNT_TOKEN behavior would remain unchanged for backward compatibility and for non-macOS users.

I recognize this is macOS-specific. A full cross-platform implementation would need equivalent support for libsecret on Linux and the Windows Credential Manager, which is a meaningful scope expansion. The macOS case alone would still be valuable even if the broader story takes longer.

No pressure

The launcher script workaround works for my use case and should work for most users who care about this. This is a quality-of-life suggestion, not a blocker. I wanted to share my approach in case it's useful to others, and to see whether native support fits the project's direction.

I also want to acknowledge the security warning in the README about secrets retrieved via MCP tools potentially being retained by LLM providers. That's a real and important caveat, but I'm talking about the service account token itself, which is the credential that grants access to the vault. That token living in plaintext in a config file is the specific thing I wanted to address. The broader point about being thoughtful with what you ask Claude to retrieve stands regardless.

Thanks for building and maintaining this — it's been a solid addition to my local AI tooling setup.