Nobody Reads Your Setup Docs

Summary

I build Hanzi Browse, a tool that gives AI coding agents a real browser. When I first shipped it, the install instructions were four paragraphs long. Different JSON snippets for different agents. Different file paths for different platforms. The kind of setup where half the people give up before they even try the product. I thought this was normal. Every developer tool has setup instructions. You read the docs, copy a config block, restart your editor. That’s just how it works. Then I saw a product where the entire install was one command. No docs. No config files. No copy-pasting. And I realized my setup instructions weren’t documentation. They were a wall between my product and the people who wanted to use it. The problem nobody talks about Right now there are over ten AI coding agents that support MCP — the protocol that lets agents use external tools. Claude Code, Cursor, Windsurf, VS Code, Codex, Gemini CLI, Amp, Cline, Roo Code, Claude Desktop. Every month there are more. They all support MCP. They all store their config in a different place. Cursor keeps it in ~/.cursor/mcp.json. Windsurf puts it in ~/.codeium/windsurf/mcp_config.json. Claude Desktop uses a path that’s different on Mac, Windows, and Linux. Claude Code doesn’t even use a config file — it has a CLI command. Cline and Roo Code use mcp_settings.json instead of mcp.json. Some agents accept comments in their JSON. Some don’t. If you build an MCP tool and want people to actually use it, you have to deal with all of this. Most developers handle it by writing a README section for each agent. Some just write instructions for one agent and add “other agents: see their docs.” The user is left to figure it out. This is the onboarding equivalent of “works on my machine.” It technically works. It practically doesn’t. What I learned from two products Nia is a YC S25 company that builds a search layer for AI agents. Their install is: npx nia-wizard@latest One command. The wizard opens your browser to sign in,...