CaptureOneAI's MCP server had been running for weeks with zero signups coming through it. The cause was dumb in hindsight: the server required an API key for everything, including initialize and tools/list, the methods a client uses to ask what are you and what can you do. Neither reads data or spends quota.
Effect: no MCP directory indexing it, since most of them probe by listing. No agent deciding whether it's worth connecting. No developer evaluating it. A catalog you have to register for before you can read it isn't a catalog.
The fix: a whitelist of description-only methods now answers without a key. tools/call still requires one, so nothing billable is exposed, and the check runs over every message in a batch, so you can't smuggle a tools/call in behind a tools/list. Verified locally: initialize without a key returns 200 and responds, tools/list without a key returns 200 and lists the six tools, tools/call without a key returns 401, and a batch of tools/list plus tools/call without a key also returns 401.
Then we published to the official MCP registry, the one backed by Anthropic, GitHub, PulseMCP and Microsoft, that feeds downstream directories and aggregators. For a remote server there's no package to publish, just metadata plus proof of domain ownership, which meant a namespace matching our domain in reverse and a DNS TXT record before the registry would accept it.
Two papercuts worth remembering for next time. The tool description silently has a 100 character limit the JSON schema doesn't declare (ours was 217, trimmed to 94), and the MCP server's container image doesn't ship curl, so its deploy health check needed to probe from the host instead of inside the container like the other services.
Published: com.captureoneai/web-perception 1.0.0, status active.
captureoneai.com
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
An MCP server can be perfectly healthy and still be invisible to its users if the tool surface is not discoverable. Logging calls is a start, but showing intent, inputs, outputs, and failure patterns gives teams a way to improve the interface instead of guessing.