For SaaS companies with a REST API
Let AI agents and a chat widget use your API as your signed-in users.
For SaaS companies with a REST API
Let AI agents and a chat widget use your API as your signed-in users.
Point us at your OpenAPI spec and tell us how your users log in. Your customers then use your product from Claude Code, Codex and other remote-MCP clients, and from a chat box on your own site. They act as themselves, within their role, through your login.
What you get
- Hosted MCP endpoint: one URL per project. Clients sign in with OAuth 2.1 (PKCE), and agents search and call your operations.
- Branded CLI + agent skill:
acme login,search,call, with the same login and roles. - Chat widget: one script tag, running on your own AI key, limited to the origins you allow.
- ask_docs: answers from your API docs, with each passage cited to its source.
Your login, your choice
| Redirect | Your login page sends the user back with their JWT. |
| Token | Your site already has the user's token. The widget trades it in (RFC 8693), with no popup. |
| Username + password | A branded form. The password is relayed once, and only the JWT is kept. |
| SSO | Google, Microsoft, Firebase or any OIDC provider. |
Safe by construction
- Your users' JWTs never reach the AI client, the CLI, the widget or the model.
- Roles are enforced: operations a role can't use never show up in search and are rejected when called.
- Deletes need explicit confirmation with a single-use token.
Try it (hosted sample)
codex mcp add acme --url https://acme-mcp.deemwar.com/mcp && codex mcp login acme claude mcp add --transport http acme https://acme-mcp.deemwar.com/mcp
A sample tenant (the fake "Acme Tasks" API; sign in as bob with any password) is live at
https://acme-mcp.deemwar.com/mcp. It runs on one demo machine, so it is down at times. In the local demo
(task demo), the first tool call by an OAuth-signed-in user came 4.2 s (machine time) after the spec was added.