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
Jose Daniel Leon Ruiz
Posted on
Our MCP server had been live for weeks. Nobody could see what it did.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (3)
This is almost exactly what happened to my MCP server, a few days after you published this. I'd closed everything behind sign-in, including tools/list, and one directory showed my server with a name, a description and zero tools. Same fix as yours, down to checking every message in a batch so a tools/call can't ride along behind a tools/list. I hit the undeclared 100-character description limit too, and the error didn't say by how much I was over.
I wrote it up as a story another person's agent can reproduce on their own server: worklore.dev/s/2026-09-27-my-mcp-s...
One thing I didn't expect once the list was open: connections jumped from dozens a day to 700–1,000, and almost all of them were directory and monitoring bots that never call a tool. Did signups actually start coming through once yours was visible, or mostly crawlers so far?
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.
Agreed. In our case the invisibility started even before the tool surface: initialize and tools/list required an API key, so directories and agents couldn't see what the server offered at all. Opening the description-only methods (and keeping tools/call behind the key) is what fixed discovery.
Your point about failure patterns is a good next step: knowing which tool calls fail, and why, says more about the interface than the raw call count.