chore: registry-listing prep — server.json, glama.json, README count, release automation

[aliasunder]

Summary

Six fixes to ready the project for MCP Registry + Glama submission and to self-validate the release path for the next cut (v0.15.3). This is step 1 of the registry-listing plan — once this lands and v0.15.3 ships, the submissions to registry.modelcontextprotocol.io / glama.ai / awesome-mcp-servers / etc. can go out.

Changes

• server.json — description. Shortened to the user-confirmed registry copy (95 chars): "Remote MCP server for Obsidian vaults — search, memory, link graph, 23 tools, OAuth-protected."
• server.json — packages[0].version. "latest" → "0.15.2" (the current released version). The release workflow's new jq clause (below) will bump it to 0.15.3 on the next cut — exercising the new automation end-to-end (0.15.2 → 0.15.3) rather than being a no-op (0.15.3 → 0.15.3 if pre-staged). Bonus: between PR merge and release cut, the OCI reference is to a tag that actually exists in GHCR.
• glama.json — new file. Glama claim manifest:

  { "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": ["aliasunder"] }

  Lets the Glama listing be claimed once it's on main.
• README.md — ## Tools (22) → ## Tools (23). The table already lists 23 rows; only the heading was stale.
• .github/workflows/manual_release.yml — jq pipeline. Extends the existing server.json version-bump step so it also bumps .packages[0].version. Single jq invocation, two assignments:

  jq --arg v "$NEXT" '.version = $v | .packages[0].version = $v' server.json > server.json.tmp && mv server.json.tmp server.json
  

  Keeps the OCI version pinned in lockstep with the top-level version on every future release.
• .github/workflows/deploy.yml — clean-semver OCI tag. Adds ${{ env.IMAGE }}:${{ inputs.version }} (e.g. :0.15.3) alongside the existing :v${{ inputs.version }} and :latest. Matches the form server.json's packages[0].version references — without this, :0.15.3 wouldn't exist in GHCR even though server.json advertises it.

Validation

• Tests: 496 / 496 pass
• Lint: clean
• tsc --noEmit: clean
• jq smoke test on the new server.json:
  • .version → "0.15.2"
  • .packages[0].version → "0.15.2" (will become "0.15.3" on next release cut via the new jq clause)
  • .description → the new 95-char copy

Follow-on (not in this PR)

After this lands, cut v0.15.3 via the Manual Release workflow. The workflow will exercise the new jq pipeline + clean-semver OCI tag end-to-end (both ship and self-validate). Once :0.15.3 is in GHCR, submissions can begin — starting with mcp-publisher publish against registry.modelcontextprotocol.io.

Submission templates for each registry (awesome-mcp-servers, wong2, modelcontextprotocol/servers, mcp.so, mcpservers.org, pulsemcp.com, Cline Marketplace) are being staged as a vault task-note alongside this PR.

[aliasunder]

Shouldn't this be 0.15.2 for now? This way the release will bump it

[aliasunder]

Agreed — pushed ac1b86e walking it back to 0.15.2. Two reasons your way is better:

1. The next release cut now actually exercises the new jq pipeline end-to-end (0.15.2 → 0.15.3) instead of being a no-op (0.15.3 → 0.15.3). If the new jq clause is broken, we catch it on the very next release.
2. Between PR merge and release cut, server.json references an OCI tag that actually exists in GHCR (:0.15.2) rather than a future one (:0.15.3).

PR body updated to match.

---

Generated by Claude Code