SEATFROG
Seatfrog Engineering · MCP Gateway

One login.
Every internal tool.

The MCP gateway puts every internal MCP server behind a single Google sign-in. Tool builders write zero auth code. You sign in once. Nobody at Seatfrog rebuilds login ever again.

Why this exists

Every internal tool needs the same thing before it can do anything useful: proof that you are who you say you are. I've built that flow several times now - browser hand-off, tokens, refresh, consent - and it's the same work every time. Only the tool changes. Worse, it gates who can build: if you cant write an OAuth flow, you cant ship an internal tool, however good the idea.

That's backwards. Auth is infrastructure, not product - so it's been pulled out into one gateway and built properly, once. Every server behind it gets the whole flow for free, and login code is now nobody's problem. Including mine, because building it yet again was becoming a genuine pain in my ass.

How it works

One front door, every tool behind it

The tool never sees a password. The gateway hands it a signed, short-lived note saying who you are. The tool reads the name and gets on with its job - it couldnt leak your credentials if it tried, because it never has them.

The first time you connect a tool

1Click Connectin Claude
2Sign in with Googleyour Seatfrog account
3Approveone screen: what, and where to
4Doneyou wont see it again

About twenty seconds, once per tool. After that the gateway verifies every call in the background - it adds about 20 milliseconds.

Included with every server

The goodies

None of this is optional extras - every server registered with the gateway gets the lot, without its author writing a line of it.

Zero auth code

A server author writes a plain MCP server and a health endpoint. That's the entire contract. Login, tokens, consent, revocation - already done.

Sign in with Google

The Seatfrog account you already have. When someone leaves, their access dies with their Google account - nothing to remember to switch off.

One consent screen

Before anything connects you see what's asking, which server it wants, and where it returns. No silent access, ever.

Scoped, short-lived tokens

A token for one server is worthless at every other. Fifteen-minute lifetimes and rotating refresh make a stolen token a short, disappointing prize.

A kill switch

Any person or any client can be cut off centrally, with a written runbook. One place to pull the cord.

Health checks, built in

The gateway probes every registered server and stops routing to broken ones - a dead tool shows up in monitoring, not in your chat window.

What it means for Seatfrog

Ship tools, not login screens

Accessible to everyone

Auth was the step that needed a specialist - if you couldnt write an OAuth flow, you couldnt ship a tool. That step is gone. Anyone who can describe what they want to Claude can get a server built and behind the gateway.

Security that's actually managed

One front door means one place to audit, one place to revoke, and offboarding that happens on its own. Six home-made login systems is six ways to get burgled.

A lower bar for useful

When the boring bit is free, small internal tools stop being blocked on a week of plumbing. More tools get built, and they get built sooner.

Build one

Get your tool behind the gateway

Three steps, and none of them is "implement OAuth".

1

Have Claude build it

Describe the tools you want - or hand over something like an OpenAPI spec - and Claude builds the server from the repo's working example. Plain code, no auth, plus a /health endpoint so the gateway knows it's alive.

2

Register it

One entry in the registry - name, URL, owner. It's a small PR to Seatfrog/mcp-gateway.

3

It goes live

Your server appears behind Google SSO with health monitoring and a plugin package in the marketplace. Done - go build the next one.

Built to be copied

The repo doesnt just hold the gateway. It ships a working example server, a local test harness that runs the entire flow on your laptop - sign-in, consent, the lot - and step-by-step registration docs. That's deliberate: they're patterns for Claude to copy, not just docs for humans.

"Build me an MCP server like the demo and register it" is a legitimate brief. The AI does the plumbing, you do the thinking, and a new tool goes online in an afternoon. A serious chunk of the work here went into making that sentence true.

And the next step is already designed: fully self-serve deploys. You hand Claude your tool code, a managed scaffold closes every conformance trap by construction, and a build pipeline does the image, the infrastructure and the registry itself - minutes later the server is live, no engineer in the loop. The approved design is in the repo: docs/superpowers/specs/2026-08-07-self-serve-mcp-deploy-design.md.

Full instructions live in the repo: Seatfrog/mcp-gateway → docs/registering-a-server.md