Repository navigation
Ownership recovery needed for existing server com.agenttrafficlab/atl #1671
Description
We need help recovering publish access to an existing MCP Registry server entry.
Server name:
com.agenttrafficlab/atl
Remote endpoint:
https://mcp.agenttrafficlab.com/mcp
Public repository:
https://github.com/wenhua6666668-oss/agent-traffic-lab-mcp
Website:
https://agenttrafficlab.com
Current situation:
- The server entry already exists in the Registry. We confirmed this because publishing a new GitHub-OIDC namespace entry using the same remote URL fails with:
remote URL https://mcp.agenttrafficlab.com/mcp is already used by server com.agenttrafficlab/atl
- GitHub OIDC authentication itself succeeds, but it only grants permission to publish under:
io.github.wenhua6666668-oss/*
So it cannot update com.agenttrafficlab/atl.
- We therefore tried the required domain-based authentication for
agenttrafficlab.comusing Ed25519. The domain proof is publicly available and the Registry reads the expected published key correctly.
HTTP proof:
https://agenttrafficlab.com/.well-known/mcp-registry-auth
Expected proof record:
v=MCPv1; k=ed25519; p=fTi1/uUQs3yuahX7HipDtResWI1TIw1MTtT3TLCBLTU=
A DNS TXT record with the same proof is also present at the apex domain.
-
The local private key is the matching Ed25519 key (64 hex chars), and the local public key derived from that private key matches the published proof exactly.
-
Despite this, both DNS and HTTP domain login attempts fail with HTTP 401. The DNS error includes:
DNS authentication failed
signature verification failed (tried published key ed25519:fTi1/uUQ...)
The Registry is therefore reading the correct published key, but signature verification still fails.
-
mcp-publisherversion used:1.8.1. -
We are trying to publish the updated manifest for version
0.1.3of the existing server, not create a duplicate server.
Could a Registry maintainer please help with one of the following:
- restore/rebind publish ownership for
com.agenttrafficlab/atlto the currently controlledagenttrafficlab.comdomain proof, or - identify why the valid Ed25519 domain signature is failing verification, or
- provide the recommended ownership-recovery path for this existing server entry.
We control the domain, the public repository, the live MCP endpoint, and the current verification record. We can provide additional non-secret diagnostics if needed. We will not share the private key.
Thanks.
Activity
wenhua6666668-oss commentedon Sep 26, 2026
Update: the public discovery repository is now fully aligned with the current production MCP surface.
Public repo:
https://github.com/wenhua6666668-oss/agent-traffic-lab-mcp
Its
server.jsonnow advertises the canonical existing namecom.agenttrafficlab/atl, remotehttps://mcp.agenttrafficlab.com/mcp,execution_mode: decision-and-execution, and the three public tools:atl_decideatl_executeatl_outcomeThe live production MCP endpoint is also serving the three-tool surface. We are still blocked only on updating the existing Registry record because GitHub OIDC authorizes
io.github.wenhua6666668-oss/*, while domain auth foragenttrafficlab.comfails signature verification with HTTP 401 despite the Registry reading the expected published Ed25519 key.We would appreciate guidance or an ownership rebind for the existing
com.agenttrafficlab/atlentry. No private key will be shared.wenhua6666668-oss commentedon Sep 26, 2026
Additional impact from the ownership blocker: downstream indexes that consume or mirror the official Registry record are still showing the stale
0.1.2/ 2-tool surface (atl_decide,atl_outcome), while the live endpoint and public discovery repo now expose 3 tools includingatl_executeand the updated0.1.3metadata.This means the stale ownership-bound Registry entry is now propagating outdated discovery data into other catalogs. We are not trying to create a duplicate; we only need to update the existing canonical
com.agenttrafficlab/atlrecord.Current canonical sources remain:
https://mcp.agenttrafficlab.com/mcphttps://github.com/wenhua6666668-oss/agent-traffic-lab-mcphttps://agenttrafficlab.comAny ownership rebind or recommended recovery path would be appreciated.
wenhua6666668-oss commentedon Sep 27, 2026
Update: ATL's canonical live MCP surface has now moved to a clearer 4-tool model-facing contract while preserving the existing advanced Decision flow.
Current live endpoint:
https://mcp.agenttrafficlab.com/mcpCurrent public tools:
atl_complete_task— default first-use tool for supported search / extract / summarize / translate / classify tasks; ATL selects and executes an eligible route in one call, may use bounded fallback, and records Outcome evidenceatl_decide— advanced routing-only Decisionatl_execute— Decision-bound ATL-owned executionatl_outcome— externally executed Outcome reportingThe public discovery repo and metadata are aligned to this 4-tool surface, and
atl_complete_tasknow publishes a structured output schema. The existing Registry ownership blocker still prevents us from updating the canonicalcom.agenttrafficlab/atlrecord, so downstream Registry consumers can continue to receive stale metadata.We are still requesting an ownership rebind/recovery path for the existing canonical entry; we are not trying to create a duplicate.
wenhua6666668-oss commentedon Sep 27, 2026
Update after the current production/discovery refresh:
com.agenttrafficlab/atlhttps://mcp.agenttrafficlab.com/mcp0.1.4atl_complete_task,atl_decide,atl_execute,atl_outcomeatl_complete_taskis now the default task-in/result-out entrance;atl_decideis advanced routing-only.The stale Registry
0.1.2record is now materially affecting downstream discovery: external catalogs that mirror/probe the Registry are still presenting the old 2-tool routing-only identity, while the canonical endpoint and public discovery repo expose the 4-tool execution-first contract.We have also rechecked the current Registry authentication documentation and the known apex-vs-selector failure mode from #1126. Our blocker is different: the published proof for
agenttrafficlab.comis already the expected Ed25519 key, and both HTTP and DNS domain authentication withmcp-publisher1.8.1 still return signature verification failure/401.Could a maintainer please help rebind/recover publish ownership for the existing
com.agenttrafficlab/atlrecord, or identify the server-side ownership/auth state that is preventing the valid domain proof from updating it? We are not attempting to create a duplicate entry and will not share the private key.wenhua6666668-oss commentedon Oct 7, 2026
Resolved on the current canonical record.
The Official MCP Registry now returns the active latest version of
com.agenttrafficlab/atlas 0.1.6:com.agenttrafficlab/atl0.1.6https://mcp.agenttrafficlab.com/mcpatl_complete_task,atl_decide,atl_execute,atl_outcomeThe domain/ownership publishing blocker described in this issue is therefore no longer preventing the canonical entry from being updated. Closing this recovery issue so old ownership-failure context is not mistaken for the current state.
Thanks.