PROP-027 — `mcp` packages: the agent-server kind and its delivery

**Milestone:** M1.26 candidate («MCP sovereignty» — [MCP-SOVEREIGNTY-PLAN-v0.1](../../../legacy-spec/terraforms/MCP-SOVEREIGNTY-PLAN-v0.1.md)).

**Status:** IMPLEMENTED — the kind and the manifest laws (§2.1–§2.3) shipped with the plan's Wave 1; the servers themselves (Waves 3–4: `mcp:org.vibevm.ai-native/rust-ai-native-mcp`, `…/typescript-ai-native-mcp`, both live-chained vibe-free); the registration lifecycle (§2.4–§2.5) with Wave 5 (`vibe mcp install/uninstall/status` speak package servers; the pin-server fixture e2e pins the walk). §2.7's composition rows inherit the kind-agnostic feature suites — no feature branches on `kind`, and the mcp e2e exercises code-bearing + binaries + the pin end to end. Units typed at REQ grain; the code carries the matching `scope!` / `#[spec(implements)]` / `#[verifies]` edges.

`req r1`

An **`mcp` package** is one whose primary deliverable is one or more Model Context Protocol servers.

`kind = "mcp"` joins the installable register (VIBEVM-SPEC §4.1); slots materialise under `vibedeps/<group>.<name>/<version>/` like every other kind (the identity slot — PROP-022 §2.1, owner ruling 2026-08-13; the path carried a kind prefix before that ruling). The `[[mcp_server]]` table (§2.2) is **legal only in this kind** — the kind IS the taxonomy, enforced by `Manifest::validate`, not advisory. An `mcp`-kind manifest that declares NO `[[mcp_server]]` is refused: the kind promises a server.

`req r1`

[[mcp_server]] name = "rust-ai-native" # agent-visible server name = the family (PROP-028 §2.4) binary = "rust-ai-native-mcp" # must match a [[binary]] in this manifest description = "AI-Native Rust discipline + type oracle over MCP" args = ["--path", "{project_root}"] The server IS a [PROP-025](../vibe-workspace/PROP-025-binary-delivery.xml) binary: delivery, consent, staleness, and slot residence come from that machinery wholesale — `binary` must resolve to a `[[binary]]` declared in the same manifest. `name` is what an MCP host shows as the tool namespace; names are unique within the package. `args` may carry substitution tokens ONLY from the closed set `{project_root}` (the absolute, verbatim-free root of the consuming project, resolved at registration time); unknown `{…}` tokens are refused at validation.

`req r1`

Cargo path-deps cannot cross package slots (PROP-024 §2.4), so an mcp package VENDORS the crates of the toolchain it serves. Vendoring re-opens the version skew the in-slot prototype excluded by construction: a server built from engine copy X enriching against a consumer whose gates run engine copy Y. The pin closes it: **every `[requires.packages]` entry of an `mcp`-kind package MUST be an exact `=X.Y.Z` requirement** — the resolver holds the served engines and the consumer's gates to ONE version set; no runtime handshake exists or is needed. `Manifest::validate` refuses any other requirement shape (caret, bare, partial `=X.Y`, compound ranges). Git-source deps pin by rev inherently; path-source deps are local-dev surfaces outside this law. The operational consequence is accepted and priced by the plan: the mcp package bumps in lockstep with the package it serves.

`req r1`

`vibe mcp install` today writes vibevm's own server into agent configs (PROP-015).

It grows package discovery: every installed package of kind `mcp` contributes its `[[mcp_server]]` entries, written into the target agents' configs with

`command` = the absolute, **verbatim-free** path to the slot-resident built artifact (a real executable — no shim, no `cmd /c` wrapper class), `args` with the closed-set substitutions resolved; a **managed sidecar**: a top-level `"vibevm": { "managed": [...] }` object in the JSON config names the entries vibevm owns (never a key INSIDE a server entry — hosts validate entry shapes), so re-installs rewrite ONLY vibevm-managed entries and operator-owned servers are never touched — the `<vibevm>` block convention of the boot files, applied to agent configs. Registration is PROJECT-scope only (the `{project_root}` substitution demands a project, and a project's servers belong in its committed config), and every project-scope agent config is JSON — so no TOML sidecar form exists; lifecycle: `vibe mcp install` re-run refreshes paths after a slot move; `vibe mcp status` reports each declared server's artifact state (an unbuilt artifact registers fine and fails at agent launch — the recipe names `vibe bin build <name>`); `vibe mcp uninstall` removes managed entries plus the emptied sidecar, and nothing else.

`req r1`

An mcp package's servers run without vibe: the artifact is launched by the agent host directly from the slot path, links its vendored engines, and speaks stdio MCP. `vibe` is required only to install, build, and register. The acceptance form of this requirement: the server's live chain passes with `vibe` absent from `PATH` and no vibevm process running.

`req r1`

Every package-role feature applies to `mcp` packages exactly as to the other kinds; no feature branches on `kind`, so each row inherits its feature's own kind-agnostic suite (the mcp-kind e2e adds the code-bearing + binaries + exact-pin composition end to end):

Feature	Spec	Composition rule
Code-bearing layout	PROP-024	the package IS code-bearing by definition; `spec/` for prompt content, crates at root
Binaries	PROP-025	`[[mcp_server]].binary` references them; `vibe bin list/build/exec` see them like any other
Skills	PROP-015 §2.8, PROP-018 §2.4	`[[skill]]` legal; a server may ship its teaching skill
Boot snippet	PROP-009	legal but not required; agents learn servers via registration, not boot text
Hooks	PROP-020	pre/post-install hooks run in the slot as usual
Materialization modes	PROP-022	snapshot/in-place per the standard rules
Bridges / submodules	PROP-023 / PROP-021	no special-casing
Publish	PROP-002 §2.10	standard registry publish; the exact-pin law travels in the manifest
In-workspace mutability	PROP-011 §2.6	dev-loop re-materialisation applies