Product Tutor

Inspiration

For years, I thought I was the only one who skipped quickstarts. Turns out, most poeple do the same thing.

Quickstarts have never really worked for me, and when I thought about why, the answer was simple: they don't know what I'm trying to accomplish. They follow a predefined path, walking me through features that might be useful, but aren't necessarily the ones I came to try.

Built-in AI agents do a much better job. I can ask for the thing I actually came for, in the order I want it. But I have to explain my setup first, and there's a harder limit. If I need to run something locally, connect an integration, or touch anything on my machine, they simply can't.

So why not use a server-side MCP server? Because a quickstart is often the first time I'm seeing a product. I'm not just checking whether it works; I'm deciding whether I want to use it. If my agent does everything through an API and hands me the result. I'm still left in an unfamiliar console with little idea of what happened or where things live.

Why WebMCP is a strong fit for quickstarts

WebMCP brings those missing pieces together.

With WebMCP, I don't need to repeat my requirements because my agent already knows what I'm trying to accomplish. And it doesn't stop there. It can work with my repo, my stack, my integrations, and my machine, while also working through the product console.

That's particularly important for a quickstart. I don't know the product yet, so seeing the interface matters almost as much as reaching the result. With WebMcp, I can watch how the task is actually done, where it navigates, what it clicks, and what values it enters, step by step.

What we built

ThunderID is an open-source identity platform under the OpenWallet Foundation. We introduced WebMCP-powered quickstarts to bring human-like guidance into the Get Started experience.

The ThunderID console registers a set of WebMCP tools, and importantly, the write tools don't call the management API directly. Instead, they open the real wizard, fill in the values, and click the same buttons a user would. Because the agent works through the actual UI, I can follow along, see where things live, and understand the product as the task gets done.

And because it's my own agent, the experience doesn't have to stop at the product boundary. If accomplishing my goal requires an integration or some local setup, the same agent can help with that too.

For example, I can give it one instruction: create an application in ThunderID, connect it to a sample app, and run it locally. It creates the application, sets the redirect URIs and requested attributes, and configures the login journey through the console I'm already signed into. I see every change happening on the screen where that setting actually lives. Then the same agent moves to my local environment, clones the sample, installs the dependencies, configures it, and runs it.

Instead of following a generic tutorial, I'm learning ThunderID by doing exactly what I came to try.

Where WebMCP changes the experience

A traditional quickstart shows me the product, but doesn't know what I want to accomplish. A built-in assistant can tailor the journey, but can't leave the product. An external agent can work with my machine, but if it does everything through APIs, it doesn't really show me the product.

WebMCP brings those worlds together.

One agent can understand what I'm trying to accomplish, work with my repo, stack, integrations, and local environment, while operating the product through the console in front of me.

The journey follows what I actually came to find out.