MCP server listings measured to first successful tool call

Listings rarely fail on copy. They fail at authentication. Across the MCP servers I have taken through Smithery, Glama, PulseMCP, mcp.so and the official registry, the median drop between install and first successful tool call has been around 60 per cent, and nearly all of it traced back to OAuth scope prompts, unset environment variables, and tool descriptions the model could not route to. Fixing that order, install path first and listings second, is the whole method. Where the work starts: A cold install, recorded, on Claude Desktop, Cursor and VS Code, from the same link a stranger would use. Every point where a human has to read documentation, generate a key or guess an environment variable name is timed. If first success takes longer than about ninety seconds, the listing programme waits until it does not. What gets rewritten: The server manifest and, more consequentially, the tool surface. Tool names become verb-first and unambiguous against the other servers a user already has installed. Descriptions are written as routing instructions for a model rather than documentation for a human: what the tool does, what it must not be used for, and what each argument means in the words a user would actually say. Read-only and destructive operations are annotated so hosts present them correctly. Overlapping tools get merged, because two tools with adjacent descriptions produce wrong selections in both directions. Listings: The directories that matter for your audience, not all of them. Each listing gets its own install path, its own example prompts, and a maintainer response drafted for the first issue filed against it. A listing you cannot support within a day earns a bad first review that outlives whatever traffic it brought. Directories selling placement are declined; purchased ranking does not survive contact with a user who cannot get the server running. Measurement: Four numbers, instrumented in your own telemetry before any listing goes live: installs, first successful tool call, tool-call error rate broken out by tool, and callers still invoking the server in week four. The error breakdown is usually the most useful part of the handover, because it names the specific tool description that is misfiring instead of leaving you to guess. Not included: Server engineering beyond manifest and description changes, protocol implementation, transport migration, hosting, or security review. If the teardown finds that the transport or the auth model is the real constraint, I say so and stop rather than dressing a listing around it. No paid placement. No review solicitation. Who this is not for: Servers not yet stable enough for strangers, since a listing converts curiosity into public issues faster than anything else you can do. Teams for whom presence on every directory is itself the objective. Anyone expecting install counts as the deliverable, because installs are the cheapest number here and the least predictive of anything. How it runs: Roughly two weeks. Cold install teardown, then the tool-surface rewrite, then listings staged one at a time so the effect of each stays separable, then a written handover with the telemetry queries. The rewrite arrives as a pull request against your repository, so your engineers can read exactly what changed and argue with any of it. Working language is English.