Summary
I'm the original publisher of io.github.traffiycom-ui/paidsync. That GitHub account has since been renamed traffiycom-ui to traffiy, so a fresh mcp-publisher login github now grants only io.github.traffiy/* and org namespaces, never io.github.traffiycom-ui/*. A PATCH /v0/servers/io.github.traffiycom-ui%2Fpaidsync/status with my current registry JWT returns 403, as expected.
Affected entry (verified 2026-09-01)
| Server name |
Version |
Status |
Remote |
io.github.traffiycom-ui/paidsync |
1.0.0 (latest) |
active |
sse at https://mcp.paidsync.ai/sse |
The remote is dead: https://mcp.paidsync.ai/sse returns 404 (the SSE transport was retired). The live, maintained entry for the same product is io.github.PaidSync/paidsync (v2.1.0, streamable-http at https://mcp.paidsync.ai/mcp), published from the PaidSync org which my current account administers.
Request
Set io.github.traffiycom-ui/paidsync, all versions, to deprecated (or deleted at your discretion), with a statusMessage like "Superseded by io.github.PaidSync/paidsync".
Proof of control
The orphaned entry's remote URL is on paidsync.ai, which I control. Happy to prove that any way you like: a DNS TXT record on paidsync.ai or a well-known file at any path you name, containing any challenge string you choose. The canonical io.github.PaidSync/paidsync entry already serves the same live mcp.paidsync.ai endpoint from the same infrastructure.
Security note, why this is more than housekeeping
The freed handle traffiycom-ui is currently unclaimed (https://github.com/traffiycom-ui returns 404). As raised in the comments of #1388, anyone who registers that handle inherits publish rights over io.github.traffiycom-ui/* and could republish this "paidsync" entry with an arbitrary remote URL, impersonating a live commercial MCP endpoint that handles ad-account OAuth. Deprecating or deleting the existing entry narrows that impersonation surface while the underlying login-string-vs-numeric-ID ownership question is open.
I'm aware of the rename-back workaround suggested in #1388 and can fall back to it in a maintenance window, but would prefer not to rename a production account if a maintainer-side status change is possible here.
Summary
I'm the original publisher of
io.github.traffiycom-ui/paidsync. That GitHub account has since been renamedtraffiycom-uitotraffiy, so a freshmcp-publisher login githubnow grants onlyio.github.traffiy/*and org namespaces, neverio.github.traffiycom-ui/*. APATCH /v0/servers/io.github.traffiycom-ui%2Fpaidsync/statuswith my current registry JWT returns 403, as expected.Affected entry (verified 2026-09-01)
io.github.traffiycom-ui/paidsyncsseathttps://mcp.paidsync.ai/sseThe remote is dead:
https://mcp.paidsync.ai/ssereturns 404 (the SSE transport was retired). The live, maintained entry for the same product isio.github.PaidSync/paidsync(v2.1.0,streamable-httpathttps://mcp.paidsync.ai/mcp), published from the PaidSync org which my current account administers.Request
Set
io.github.traffiycom-ui/paidsync, all versions, todeprecated(ordeletedat your discretion), with a statusMessage like "Superseded by io.github.PaidSync/paidsync".Proof of control
The orphaned entry's remote URL is on
paidsync.ai, which I control. Happy to prove that any way you like: a DNS TXT record onpaidsync.aior a well-known file at any path you name, containing any challenge string you choose. The canonicalio.github.PaidSync/paidsyncentry already serves the same livemcp.paidsync.aiendpoint from the same infrastructure.Security note, why this is more than housekeeping
The freed handle
traffiycom-uiis currently unclaimed (https://github.com/traffiycom-uireturns 404). As raised in the comments of #1388, anyone who registers that handle inherits publish rights overio.github.traffiycom-ui/*and could republish this "paidsync" entry with an arbitrary remote URL, impersonating a live commercial MCP endpoint that handles ad-account OAuth. Deprecating or deleting the existing entry narrows that impersonation surface while the underlying login-string-vs-numeric-ID ownership question is open.I'm aware of the rename-back workaround suggested in #1388 and can fall back to it in a maintenance window, but would prefer not to rename a production account if a maintainer-side status change is possible here.