The fastest way to put your SaaS inside Claude and ChatGPT is to ship an MCP connector: a hosted MCP server your customers install by pasting one URL. The assistant handles login through OAuth, your customer approves access on a consent screen, and from then on they use your product by asking for things in plain language. On DenkOps the hosting and the entire OAuth flow are handled for you. What you build is the part only you can build: the tools.
Why would my customers want this?
Because their assistant is where they already work. A customer who can say "pull last month's invoices from Acme and summarize the overdue ones" will not open your dashboard, export a CSV, and upload it. Connectors are becoming the integration surface assistants expect, the way app marketplaces were for the last platform shift. Being installable means being usable in the middle of someone else's workflow, which is where product usage actually grows.
The alternative is watching customers paste API keys into assistants anyway, with no per-user identity, no consent step, and no revoke button.
What do I actually have to build?
Be honest about the split. DenkOps gives you:
- Hosting in an always-on slot with a stable HTTPS URL and an
/mcpendpoint. - The full OAuth stack behind one flag: discovery, dynamic client registration, login, and a consent screen. Your code contains zero auth plumbing.
- Access control per project, and an audit trail of every grant.
You still build the product surface: the tools themselves. Which actions should an assistant take on a customer's behalf? What inputs do they need? What does a good error look like? That is real design work, tools are your API rethought for an agent, not a wrapper around every endpoint you have. Start with the three actions customers do most, not thirty.
The config is the smallest part:
{ "name": "acme-tools", "slug": "acme-tools", "runtime": "bun", "connector": true }How do I roll it out without opening the doors?
Every connector has an owner-controlled access policy, and it maps cleanly onto a product rollout:
- Design partners first. Set the policy to an allowed-email list in the project's Access tab and add five friendly customers. Everyone else is refused at login, before a single tool call reaches your code.
- Widen the list. Add customers as they ask. Each grant is individual and auditable, so "who can reach this" always has an answer.
- Go public. Flip the policy to public and anyone who completes the OAuth flow can install your connector. Announce the URL, or put it on a custom domain first so the endpoint carries your brand.
No code changes between the stages, only the access policy moves.
What does installation look like for a customer?
They paste your URL into their assistant as a custom connector or remote MCP server, for example in Claude or ChatGPT. The client discovers OAuth on its own, shows your consent screen, and the customer signs in. No API key exchange, no setup call, no docs page explaining where to find a token. If they can paste a URL, they can install your product.