Paste your MCP server's URL. Get one with a lock on it.
Innkeeper puts OAuth in front of your server, and your phone in front of the calls you would rather look at first. Nothing to install in your server, no SDK, and no password anywhere.
- Yours
- https://tools.acme.dev/mcp
- Ours
- https://innkeeper.a2w.io/s/acme
Give the second one to Claude. It is the same server, with a door.
How it works
Pair your phone
Scan a QR code with the Innkeeper app. That is the whole signup. There is no password to pick and none to leak later.
Paste your server
Give us the URL your MCP server already answers on. You get back an address on innkeeper.a2w.io that points at it.
Hand that address to Claude
Claude gets a 401, reads our metadata, and walks the OAuth flow itself. Your phone buzzes, you look at it, and the connection is live.
The part worth paying for
Mark a tool "ask me" and every call to it stops here first.
Your phone gets the tool name, the arguments as they were actually written, who asked, and how long the request has left. Approve with Face ID or deny. The agent waits, then carries on with your answer as an ordinary tool result, so this works with every MCP client alive today.
- The phone signs those exact bytes. An approval is a signature over the request you were shown, not a message that says yes. Nothing can be swapped in between the screen and the run.
- The key never leaves the Secure Enclave. Not on our servers, not in a backup, not anywhere we could be compelled to hand it over.
- Everything is written down. Every gated call, its arguments, your verdict and the time, in an audit log you can read.
The auth, specifically
OAuth 2.1, built to the MCP specification of 28 July 2026 rather than to a draft of it.
- Discovery that works on its own. An unauthenticated call gets a 401
and a
WWW-Authenticateheader pointing at RFC 9728 protected resource metadata. The client takes it from there. - PKCE, always. No implicit grant, no password grant, and an
isson every authorize response for the client to check before it redeems a code. - Tokens that only work here. Resource indicators per RFC 8707 on both legs, and a token minted for someone else's server is refused rather than forwarded.
- No token passthrough. Your upstream server's own credentials stay upstream. We never hand a client's token to it and never accept one meant for it.
- Client ID Metadata Documents. The registration path the current spec prefers, with dynamic client registration still answering for clients that have not moved yet.
- Consent is a face, not a form. What happens inside an authorization server is ours to decide, so we made it a push notification and Face ID.
Two ways to run it
We sit in the path
To draw a tool call on your phone we have to read it. So on the hosted side we see every call and every argument in plain text. We would rather say that than have you find it out. It is the trade you are making. A URL that works in a minute, in exchange for trusting a middle.
Nothing to run, nothing to keep awake.
We see nothing
Run the daemon on your own Mac and the approvals go straight from it to your phone. When they travel over our relay they travel sealed, and the relay moves envelopes it cannot open.
Same app, same phone, same signature. You keep the machine awake.
Pricing
- One server, one phone
- 100 approvals a month
- Full OAuth 2.1 on your server
- Seven days of audit log
- One server, one phone
- Approvals, no monthly cap
- Full OAuth 2.1 on your server
- Audit log kept for a year
- Answers by email from a person
- More than one server and more than one phone
- Roles, and who may approve what
- Self-hosted, or run inside your own cloud
- Audit export, SSO, an agreement with terms in it