I started writing MCP servers in early 2025. The first one was a Google Ads MCP for Claude Code. The second was Gmail. The third was Search Console. By the time I hit five servers, I noticed the same code in every repo: read refresh token from env, call Google’s token endpoint, cache the access token, repeat.
By server number ten, I had a bug. Microsoft Graph rotates its refresh token every time you use it. I had two MCP servers refreshing the same Microsoft token simultaneously, and one of them was always getting locked out. The fix was a shared service that serialized refreshes.
That shared service became MCP Factory.
The problem with per-server credential storage
Every MCP server I wrote was a credential store. That means:
- N copies of every refresh token. Rotate the Google client secret, update N repos.
- N places a token can leak. A logged exception in one repo can dump a refresh token.
- No central revocation. A user wants to disconnect Gmail? Hope you remember which servers cached their token.
- Different bugs in different repos. Server A refreshes correctly; server B forgot to handle the 401-then-retry case.
A small FastAPI service that just held the credentials and handed out fresh access tokens on demand solved every one of these.
What “factory” means
The “factory” name is on purpose. The service doesn’t do business logic. It doesn’t talk to Google Ads or send GHL messages. It manufactures fresh access tokens for any MCP server that asks. You point your MCP server at it, you stop thinking about OAuth.
What’s next
Today MCP Factory is open source, self-hostable, and there’s a hosted version at app.mcpfactory.io. Roadmap: more integrations, SOC 2, role-based access for teams, and a Terraform provider so you can manage credentials as code.
If you’re shipping MCP servers, grab the source or start a free trial.