LabscoMCP early access ↗
JktfeMCP SERVER

ServeMyAPI

Keep API keys in the macOS Keychain and hand them to an assistant on request, instead of scattering .env files across projects.

by Jktfe ↗Identity, Access, Secrets & EncryptionCommunity

LABSCO SUMMARY

Solves the .env problem the way a keychain already does.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

Build from source — git clone https://github.com/Jktfe/servemyapi.git

See installation options