Outreach: MCP registry submission + Glama claim + awesome-list PR follow-ups

[asklokesh]

Outreach: MCP registry submission + Glama claim + awesome-list PR follow-ups

Status: technically fire-ready; the remaining steps are founder browser actions + maintainer merges.

MCP registry (FIRE-READY, needs founder browser ~2 min)

• Published loki-mode@7.34.x has mcpName: io.github.asklokesh/loki-mode (the registry ownership marker). VERIFIED.
• Published-package MCP handshake verified: fresh install + project venv + full initialize -> notifications/initialized -> tools/list returns 34 tools over stdio.
• Server.json entry is staged (90-char description to pass the 100-char server-side cap). Full runbook: internal/outreach-staged/mcp-registry-submission.md (refreshed to 7.34).
• BLOCKER: the registry publish needs an interactive device-code auth (GitHub OAuth) the founder runs in a browser; the poller/flow is restartable.

Glama (badge GREEN, needs founder web claim)

• Glama's clean-room introspection passes (34 tools from the published Docker image; the v7.31.0 Dockerfile ships mcp/requirements.txt). Section 6b walkthrough in internal/outreach-staged/mcp-registry-submission.md.
• BLOCKER: interactive web repo-claim (founder), then post the gated-badge comment on the Glama tracking issue.

Awesome-list PRs (await maintainer merge, monitor)

Open PRs (as of 2026-06-11):

• Add Loki Mode as an AGENTS.md adopter agentsmd/agents.md#201 (AGENTS.md adopter)
• Add Loki Mode to Coding Agents punkpeye/awesome-mcp-servers#7736 (Coding Agents)
• Add Loki Mode under Orchestrators and autonomous loops bradAGI/awesome-cli-coding-agents#121 (Orchestrators)
• Add Loki Mode to Terminal Agents jamesmurdza/awesome-ai-devtools#635 (Terminal Agents)
  One already merged earlier (state-machine doc / eltociear). Action: monitor, nudge if stale, respond to maintainer review comments.

Cold-launch UX note (founder decision, non-blocking)

loki mcp over piped stdio is non-interactive and exits 2 without the MCP SDK present (never auto-installs). A registry consumer with the SDK (or who runs the documented bootstrap) gets the 34-tool handshake. Founder may decide whether to soften this UX later.

[asklokesh]

Status refresh 2026-07-30 (verified via gh, not assumed). The four awesome-list PRs are NOT all still open -- two closed with opposite outcomes:

PR	State	Outcome
bradAGI/awesome-cli-coding-agents#121	CLOSED	MERGED and live (commit c0ee24a, star count refreshed). A win nobody recorded.
punkpeye/awesome-mcp-servers#7736	CLOSED	Auto-closed for 45 days of author inactivity -- not rejected. Recoverable.
agentsmd/agents.md#201	OPEN	last activity 2026-06-10
jamesmurdza/awesome-ai-devtools#635	OPEN	last activity 2026-06-15

#7736 is the recoverable one and the path back is explicit. The maintainer wrote: "reopen this one and ping me when the Glama listing checks pass", and earlier: "Once it is listed with a quality score (any grade is fine), just update the PR with the Glama badge and I will be happy to merge."

So the merge gate is a Glama listing with ANY score, not a good one. Per this issue, Glama clean-room introspection already passes (34 tools from the published Docker image).

Exact remaining sequence:

1. Claim the repo on https://glama.ai/mcp/servers (browser, founder -- interactive web claim, I cannot do this)
2. Wait for the quality score to populate (any grade qualifies)
3. Reopen #7736, add the Glama badge, ping the maintainer

Steps 1 and 3 are browser/OAuth actions. Everything technical is already done.

Also fixed today: server.json was pinned at 7.34.1 while the repo shipped 8.2.0 -- thirty-plus releases of drift on the MCP registry submission manifest. Now current and enforced by tests/test-server-json-current.sh, so a future submission advertises the shipped version rather than a stale one. That test also pre-checks the two things that would reject a submission AFTER the interactive OAuth: the server-side 100-char description cap (currently 92) and the package.json mcpName ownership marker.

[asklokesh]

Re-verified the technical preconditions at v9.19.1 (the issue's evidence was from 7.34.x, ~180 releases ago). All still hold. This remains founder-browser-action-only; there is nothing left for me to build.

Precondition	v9.19.1
mcpName on the PUBLISHED package	io.github.asklokesh/loki-mode -- present
server.json version tracks VERSION	9.19.1 -- in sync
Published-package MCP handshake	responds to a real initialize

The handshake was driven against the SHIPPED TARBALL, not the working tree:

npm pack loki-mode@9.19.1 && tar xzf loki-mode-9.19.1.tgz
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' \
  | python3 package/mcp/server.py

Returns a valid result advertising tools, resources and prompts. That distinction matters: everything works from a git checkout, so only a tarball probe can confirm a registry submission would find a working server.

Worth noting the drift risk this closes: server.json silently sat at 7.34.1 for 30+ releases at one point, which is why tests/test-server-json-current.sh exists. It is in sync today.