Support post-install lifecycle hints for servers that double as system services

Problem

mind-map is an MCP server that also functions as a persistent system service. It runs in two modes:

1. stdio: AI agents spawn it as a subprocess (standard MCP transport)
2. mind-map serve: a persistent HTTP daemon serving a web UI for humans at localhost:4242

Both modes share the same wiki directory via SQLite locking. The MCP side works immediately after MCPB download, but for the companion web UI, users need to register it as a system service (mind-map service install). Nothing in the current server.json schema communicates this. The websiteUrl field can point to docs, but clients have no structured way to surface post-install steps.

Proposed solution

Structured post-install instructions that clients can display as a checklist after downloading an MCPB package:

"packages": [{
  "registryType": "mcpb",
  "identifier": "https://github.com/...",
  "transport": { "type": "stdio" },
  "postInstallInstructions": [
    {
      "description": "Install as a system service for the web UI",
      "command": "mind-map service install --addr 127.0.0.1:4242",
      "documentation": "https://github.com/aniongithub/mind-map#service-management",
      "optional": true
    }
  ]
}]

optional: true signals the MCP server works without it. Clients only display text, no execution, so there is no supply chain risk.

Questions

1. Is this something the spec intends to address, or is it deliberately out of scope?
2. In the meantime, is _meta.io.modelcontextprotocol.registry/publisher-provided the right place to experiment with this convention?

Start by reviewing the current server.json package schema and the existing publisher-provided metadata convention. Compare the proposed postInstallInstructions fields with the schema's scope and determine whether this needs a specification change or an experimental convention; done means the scope and schema location have been decided.