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

[aniongithub]

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?

[friendlygeorge]

Feasibility Analysis

This is well-scoped and the schema change is clean. Here's how I'd approach it:

Schema design:

The field fits naturally alongside and in the Package definition. A minimal schema:

postInstallInstructions:
  type: array
  description: Structured post-install steps clients can display as a checklist after downloading a package. Useful for servers that double as system services.
  items:
    : '#/components/schemas/PostInstallInstruction'

Each instruction could be:

PostInstallInstruction:
  type: object
  required: [description]
  properties:
    description:
      type: string
      description: Human-readable instruction text
    command:
      type: string
      description: Optional shell command the user should run
    url:
      type: string
      format: uri
      description: Optional link to documentation or setup page

Implementation path:

1. Add schema to
2. Add field to the definition
3. Run to regenerate
4. Add test data in the test fixtures
5. The API layer (Go structs) would need a corresponding field in the internal Package type

Scope check:

This doesn't affect the publish flow or server validation logic, just the metadata schema and the API response shape. Low blast radius. The main decision is whether this belongs in the core Package schema or as an extension, since the registry already has an extensions mechanism (per ).

Happy to implement this if the approach looks right.