The argument in the README is a real one: .env files are gitignored, which makes them invisible to collaborators and to the assistant that needs the key. Putting the keys somewhere the assistant can ask for them by name fixes both. The security model depends entirely on this staying local — the README is blunt that the Smithery-hosted deployment is a demo and should not hold real keys.
A local credential store exposed over MCP. Keys live in the macOS Keychain — or in AES-256-GCM encrypted file storage on Windows, Linux and Docker — and an assistant asks for one by name when it needs it.
- store-api-key saves a key under a name you choose
- get-api-key retrieves it by that name
- list-api-keys enumerates what is stored, and delete-api-key removes one
- The same keys are reachable from every project, so a rotation is one update rather than one per repository
- A CLI covers the same ground from the terminal: api-key list, api-key get, api-key store, api-key delete
- Storage picks itself per platform — Keychain on macOS, encrypted file storage elsewhere, in-memory for testing — and SERVEMYAPI_STORAGE_TYPE overrides the choice
- HTTP and SSE transports exist behind Bearer token authentication set through SERVEAPI_AUTH_KEY
A checkout built with `npm install` and `npm run build`, then run as a stdio server with `npm start`, or over HTTP with `node dist/server.js`. On macOS the Keychain asks for permission the first time. File storage requires an ENCRYPTION_KEY, and the HTTP transport requires SERVEAPI_AUTH_KEY.