Skip to content

ck-mcp-stdio-adapter: generic subc-module face for stdio MCP servers (plexus#4 end state) #20

Description

@ualtinok

Disposition from plexus#4 (operator with 19 stdio-spawned MCP backends evaluating plexus as gateway): the end state is GOVERNED BUT NOT SPAWNED-BY-PLEXUS — each stdio server becomes a subc module via a generic adapter binary.

Shape: one Rust crate. subc-module face (HELLO, manifest projecting the child's MCP tools, health on an insulated lane per HPR-v3, route serving) on one side; MCP-over-stdio client on the other. Child lifecycle is ADAPTER-INTERNAL per the AFT per-root-idle-evict precedent: spawn on first call, shed after configurable idle (operator's requirement: 300s), respawn on demand, restart budget for the child distinct from the module's own. subc supervises 19 few-MB resident adapters; the heavy node/python children exist only while in use. Plexus governs every call over the route plane (catalog, risk, grants, drift) and grows no process machinery.

Refused alternatives on record: plexus spawning children directly (second supervisor + places npm packages beside the credential binding key AS A DESIGN PROMISE), daemon-level lazy modules (lifecycle feature the adapter owns one layer down), permanent out-of-scope (real consumer, common inventory shape). Bridge (operator's gateway as one mcp_remote backend) stands as the migration path only — it loses per-backend governance.

Waits on: Ufuk's decision on the plexus#4 public reply (PLEX carries it), then scheduling.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions