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

2.1 The mcp kind

05req r1

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

• 07kind = "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.

2.2 The [[mcp_server]] declaration

08req 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}"]

• 10The server IS a PROP-025 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.

2.3 The exact-pin law

11req r1

• 12Cargo 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.

2.4 Registration: vibe mcp install learns packages

13req r1

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

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

• 16command = 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.

2.5 Consent: registration is the same trust act as building

17req r1

• 18Registering a server schedules package code execution at agent-session start; building its binary compiles package code.
• One trust model, two verbs: registration inherits PROP-025's consent gate verbatim — org.vibevm packages are allow-listed; any other origin requires the explicit --assume-yes (or is refused with the recipe naming that exact flag).
• Registration writes touch ONLY the target agent's config files and only managed entries; server processes receive the project root as cwd and NO secrets from vibe.

2.6 Serving is vibe-free

19req r1

• 20An 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.

2.7 Composition: an mcp package is a full package

21req r1

22Every 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):