Distribution: improve discoverability, README, and installation guide

[dkijania]

Context

mina-mcp-server is functional across snapshot / tutorial / live modes and has a hosted sandbox on Fly.io, but it's effectively undiscoverable today and the README's onboarding path is patchy. To move this from "demo project the authors know how to run" to "MCP server a Mina-curious AI developer can wire up in five minutes," we need a coordinated distribution pass.

Goals

• A new user can pick the right mode, install, and verify it works in under 5 minutes.
• The project shows up when someone searches an MCP registry for "Mina" / "blockchain".
• The README answers "how do I plug this into my MCP client" for every major client, not just Claude Desktop.

Scope

1. Discoverability

• List the package in public MCP registries:
  • modelcontextprotocol.io servers list
  • smithery.ai
  • Anthropic's MCP marketplace (when accepting submissions)
• Add GitHub repo topics: `mcp`, `model-context-protocol`, `mina`, `mina-protocol`, `blockchain`, `ai-agents`.
• Set a one-line repo About description that mentions MCP + Mina.
• Add README badges (npm version, license, MCP-compatible, Fly deploy status).
• Cross-link from the MinaProtocol/mina README under a "Tooling" / "AI integrations" section.

2. README rework — installation guide

The current "Using with Claude Desktop / Claude Code" section only shows one snippet (snapshot mode via npx). We need:

• A config-snippet matrix covering (mode × network × client). At minimum:
  • Modes: `live`, `tutorial`, `snapshot`
  • Networks (live only): `devnet`, `mainnet`, `mesa`
  • Clients: Claude Desktop, Claude Code, Cursor, Continue, Cline, Windsurf, Zed
  • Hosted (Fly URL) vs self-hosted (npx) variants of live mode.
• Decision flow at the top: "Which mode do I want?" → 2–3 sentences each, pointing to the matching snippet. Most users will want `live`; the README currently buries it under `snapshot`.
• Verify-it-works smoke test: after installing, paste this prompt → expect this output (e.g. `describe_state` returning SYNCED). Gives users a green-light moment.
• Troubleshooting section: common failure modes (Node version, port conflicts on tutorial mode, stale dist/, MCP-Session-Id on hosted, preflight network warnings).
• Drop the stale Roadmap items: "Live mode" is shipped, not future work — currently misleads readers about what works today.

3. Installation friction

• Make sure `npx @o1labs/mina-mcp-server@latest --mode live --network devnet` works end-to-end with no clone (verify the npm tarball contains `dist/` and a proper `bin` entry).
• Add `--help` output snapshot to the README so users can see the full CLI surface without reading source.
• Add `--version` flag if missing.
• Document the env-var equivalents (`MINA_MCP_MODE`, `MINA_MCP_NETWORK`, …) in one place as a table — they're scattered today.

Non-goals

• Building a new hosted endpoint per network. The Fly sandbox stays as-is; live mode is intended to be run locally by the user via npx (cheaper, no SLA expectation).
• Marketing copy. This is an engineering/docs cleanup, not a launch.

Suggested order

1. README rework (1 + 2) — biggest UX win, unblocks everything else.
2. CLI polish (3) — `--help` and tarball verification.
3. Registry submissions (1) — only worth doing once the docs are decent, since registries will link straight to the README.

Acceptance

A first-time visitor who knows nothing about Mina or this repo can:

1. Land on the README.
2. Pick a mode in <30 seconds.
3. Copy one config snippet into their MCP client.
4. Run a one-line smoke prompt and see a `SYNCED` response.
5. Find at least one of the major MCP registries listing this server when they search "Mina".