Curiosity has a half-life

Most of the interesting servers I've used in the last six months were ones a colleague mentioned over coffee. Almost none of them were ones I read about online and went on to install. The difference isn't quality. It's the gap between hearing and trying.

Curiosity has a half-life. When you first hear about something, the cost you're willing to pay to look at it is highest. Every minute that passes between that first spark and your first hands-on impression, the cost-tolerance drops. By the time you've cloned a repo, configured a client, written a glue script, and remembered which API key to plug in, the curiosity is usually gone.

The shape of the problem

It's worth being precise about where the time goes. In a small survey of MCP server installs we ran last month, the median time from “I want to try this” to “a tool ran” was 47 minutes. About 8 of those were spent reading the README. The other 39 were spent on environment setup, credential plumbing, fighting a Python version, or rewriting an example to fit the user's actual client.

That 39 minutes is what kills momentum. Not because 39 minutes is a lot in absolute terms — it isn't. But because curiosity rarely lasts that long. The signal that brought you to a server in the first place doesn't survive being interrupted by a yarn install.

Why this compounds

The friction isn't just bad for the developer trying a server. It's bad for the ecosystem. Every server author is, in effect, paying their users' setup tax in the form of feedback they never get. The people who would have been the most useful early adopters — the ones who heard about your server, formed an opinion in three minutes, and told you what was wrong — those people don't make it past the install.

What you get instead is a survivor's bias of users who were already determined to make your server work. Their feedback is valuable but narrower. They'll tell you about edge cases. They won't tell you that your tool description is misleading, because by the time they got to your tool, they'd already read the README three times.

What fast buys you

When the time-to-first-tool-call drops below a couple of minutes, something changes about how people interact with the ecosystem. Servers stop being investments. They become things you try the way you try an app on your phone — for thirty seconds, often, just to see what they do. Most get closed and forgotten. A few stick. The ones that stick are the ones whose value was actually obvious in thirty seconds, which turns out to be a useful filter.

• Authors get faster, more honest feedback because the people giving it haven't yet sunk-cost themselves into making it work.
• Users build a mental model of what's available without needing to commit to anything.
• Conversations about MCP shift from 'have you set up X?' to 'have you looked at X?' — a much lower-stakes ask.
• Bad servers are filtered out faster, which is good for everyone, including their authors.

What we built about it

MCPOrbit started with a single design target: drop the time from curiosity to running a tool below two minutes, on the worst day, on a fresh laptop. We didn't always hit it. The version that ships today usually does. The shape of the app — three primitives, no accounts, no project files — is mostly a consequence of that one number. Everything that would have made the app more powerful would have made it slower.

If you build MCP servers and you've never watched someone evaluate yours from cold, it's worth doing. Watch the cursor, not the face. The places they pause are the places curiosity is leaking out.