Every tool that requires any configuration to install has a setup tax — the friction between “I want to try this” and “I can actually use this.” For developer tools, the tax is often acceptable. For tools targeting non-technical professionals, it’s a meaningful conversion barrier that the builder owns.

MCP tools for professional workflows have a specific version of this problem. The installation path requires Claude Desktop, a configuration file in JSON format, and correct paths and credentials for the server in question. None of these are impossible. A motivated professional who really wants the tool will work through it. But “motivated enough to work through a JSON config file” is a higher bar than “interested in trying this,” and you lose prospects at the gap.

The builder’s job is to make the setup tax as low as possible without making it zero — because some friction in setup actually serves a purpose. A professional who has invested fifteen minutes setting up a tool has made a commitment to evaluating it seriously. They’re not going to close the window the moment the first result isn’t perfect. The setup creates a small stake that changes how the evaluation proceeds.

But fifteen minutes of carefully followed documentation is very different from an hour of debugging path issues, permission errors, and unclear error messages. The former is an investment; the latter is just frustrating, and frustration ends evaluations.

The practical work of minimizing the setup tax for a non-technical audience has a few components. First, a single-page installation guide written for the specific audience — not generic MCP documentation, but instructions that assume the exact configuration the target user has (Claude Desktop, Mac or Windows, the specific server). Second, a clear first-use experience: what should the user do first, and what should they see when it works? Without a defined success state, users don’t know if the setup worked. Third, error recovery paths: what are the three most common setup failures, and how does the user fix each one? Getting setup right for 80% of users is not enough if the other 20% just give up.

The counterintuitive implication is that the setup experience is part of the product, and the builder should own it as such. When a prospect asks a question about installation, that’s not support overhead — that’s product feedback about where the setup tax is too high. The first ten installation conversations are worth more than any amount of documentation writing, because they reveal exactly where the tax is causing people to stop.

The goal is a setup experience where a professional who has never configured an MCP server before can get from “I downloaded the installer” to “the tool is running on my first document” in under ten minutes. That’s achievable. It takes work to get there, but the work is invested once and pays off across every future installation.

+++