← Insights

MCP Discoverability Hack

After the 30-Minute Rule says yes, I wire the MCP into Cursor and run four prompts—stack compare, backlog impact, time-to-market, and revenue wild card—without falling back into build mode.

Stephan Smith
Stephan Smith

5 min read

Founder Mindset

New technology is one of my vices. I love trying out new solutions.

But I hate the revenue impact that comes with new technology discoveries.

For the past month, I have been finding balance by using MCPs to assist my evaluation of solutions and approaches. Recently, I got turned on to Lux.dev. The founder is a friend. He describes it as a drop-in replacement for Supabase.

Since Supabase is a key part of my go-to tech stack, I was interested.

This is not a review of Lux. Still too early. :)

My problem

I love to try out new tech. But as a solo operator trying to balance the challenges of building and operating a business, I have to be very aware of how I allocate my time.

I know I have this problem. One of the benefits of being a serial startup founder is that I know how I win, and am very aware of how I fail. Done it enough to know. So I keep a close watch on when I let myself fall back into build mode. See The 30-Minute Rule.

My solution

Recently, I wrote about my MCP bench approach. More and more I have been using Cursor and its MCP tooling to solve problems in my startup; Sentry error that needs debugging, scaling, etc.

All this work with MCPs has given me an unexpected new tool to keep my build-mode vices in check.

I already have my 30-Minute Rule. That has worked well enough. But I still slip.

Enter my new approach

I use an MCP to find ROI in my stack.

Even if I am not using a new solution, I set up an account, obtain an API key, and configure my Cursor environment with MCP access. This means that Cursor can do part of the tech eval. The parts that I wish I had more time to do.

When you enable an MCP in Cursor, it tells you how many ‘tools’ the MCP enables. Who has the time to read all the documentation and or review and test each tool for its ability to impact revenue?

Prompt 1: “Review the new MCP for Resend.com. I want you to evaluate all the features and tools available in the MCP, compare them to what we have in our current Postmark integration. Build a report of new, replacement, or missing. And include an evaluation of the level of complexity required to replace or add.”

Prompt 2: “Review the tooling available in the MCP and assess the issues in our backlog. How would using this solution impact the features we have ready to build, either positively or negatively?”

Prompt 3: “How would this solution impact our time to market for features, user experience, or our long-term strategy and go-to-market plan?”

Cursor MCP panel — GitHub MCP showing 44 tools, 2 prompts, and 4 resources enabled

My wild card prompt

This final prompt is the one that brings the most joy. It’s less about evaluation and more about planning and finding solutions for the future.

Prompt 4: “Evaluate each element of our tech stack and outline how the adoption of this solution would or could provide revenue.”

This last prompt gives me the wildest results. It’s less analytic and more thoughtful. It only works if I have already built our knowledge base, strategy, and roadmap. Basically, the more the bench knows about the why of what I am building, the better it does.

I found the webhook feature in ImprovMX via a convo with the MCP.

ImprovMX alias routing — store@lowcodecto.com forwarding to a Supabase webhook URL

Why does this work?

More than once, I have found solutions via this process that I would never have found from the sales materials. For the last four years, I have been interviewing Techstars founders and CTOs. Countless times, I find that the features they think a customer wants are 180 degrees off-axis from what I actually value.

Formalizing

Finally, I got tired of writing these prompts over and over.

So I rolled them into a skill that knows its role. I even told the skill to store the evaluation, each time I use it, so that I can be told ‘good boy’ during my monthly AI review. I find it helpful to know that the approaches I adapt are having an impact.

Without this approach

This approach has helped me to stay in operations mode and fight the urge to drop back into build mode. I have an impact in operations mode, I talk to clients, I grow my user base, and revenue goes up. But my coder brain still likes to pitch me on ideas that one more feature will bring in revenue.

If you read my other stuff, you will know that I have had my 30-Minute Rule for years. This builds on it.

See also