Registry entry publishes a URL with the placeholder still in it — the server is fine

I probed every remote endpoint advertised in the official MCP registry (10,519 of 10,542 reached). `io.aiven/mcp` came back flagged, and the cause is narrow: **your server answers correctly and the published URL is not usable.**

## The measurement

```
alive-gated https://mcp.aiven.live/mcp?read_only={read_only}&services_scope={services_scope}&allow_secrets={allow_secrets}
```

`{read_only}`, `{services_scope}`, `{allow_secrets}` are literal in the published value. It sits in the **query string**, which means the host and route resolve, and your server receives the literal string as a credential.

Your server returns a proper auth response when probed, which is exactly right — nothing is down and nothing is misconfigured on your side. The only broken component is the string in the catalogue.

Because a healthy server generates no error report, nothing was ever going to surface this to you.

## Reproduce

```sh
curl -sS -o /dev/null -w '%{http_code}\n' -X POST 'https://mcp.aiven.live/mcp?read_only={read_only}&services_scope={services_scope}&allow_secrets={allow_secrets}' \
-H 'content-type: application/json' -H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"p","version":"1"}}}'
```

## It is not just you

**171 of 10,542 advertised endpoint URLs (1.62%) carry a literal placeholder, across 115 distinct publisher namespaces.** 79 of them have it in the hostname, so those never resolved at all. **47 sit in front of servers that are alive and answering properly** — working products with unusable listings, which is the category yours is in.

I am raising a publish-time validation rule with the registry separately, since 115 publishers hitting the same wall is a missing guardrail rather than 115 mistakes.

## Why check rather than believe me

My prober was wrong four times on the day I ran this, and the first three errors all ran the same direction — toward over-accusing. I published an ecosystem rate of 14.4%, then 12.2%, then 11.5%, correcting each within hours. That directional bias is now published alongside the rate.

This particular finding does not depend on the prober at all — it is a string match against your published field, checkable without any network call.

Method, data, prober and the control-stratum verifier: https://github.com/siliroid/mcp-endpoint-census

Nothing needed from me. Raising it because a working server being unreachable through the registry seemed worth someone mentioning.