D5-S14 — Mcp: the frozen catalogue and its startup checks

[The-Running-Dev]

A product can offer tools to an AI client from two independent sources — a manifest it ships and its own code — with neither privileged over the other. Nothing is offered to anyone until someone explicitly says so, and a tool that could ask for a password never gets as far as running.

Done when

• S14.1 A manifest-projecting producer and a product-owned fixed-table producer both register through the same interface, and the catalogue treats them identically — no ordering, capability or schema-derivation difference between them.
• S14.2 ToolDefinition declares no exposure member — asserted over the type. Exposure comes only from configuration.
• S14.3 A registered tool absent from the exposure configuration is not in the catalogue's exposed set, and looking it up answers exactly what looking up a name that was never registered answers.
• S14.4 IToolCatalogue declares no member reaching an unexposed registration — no enumeration of all registrations, no exposure-ignoring lookup.
• S14.5 A registered tool whose parameter schema names a parameter matching the redaction marker set fails startup with HostStartupError.SensitiveToolParameter, naming the tool and the parameter.
• S14.6 A tool requiring a permission no catalog declares fails startup with HostStartupError.UnregisteredPermission.
• S14.7 Each producer's production runs once at startup and never again, and the catalogue exposes no registration, unregistration or re-exposure member.
• S14.8 An architecture test asserts ModelContextProtocol.* is referenced by the Mcp module and by no other package, and that no Platform public type exposes, returns, accepts or derives from an SDK type.

---

Agent instructions

Run /slice S14.

• Scope and criteria: design/30-slices.md § S14 @ d752008
• Signatures: design/20-contract.md
• Depends on: S8.
• Out of scope here: the transport, the connection principal and invocation, which are S15.

Stop conditions and procedure: .claude/commands/slice.md. Not restated here.

[The-Running-Dev]

Closed via merge of PR #220, but S14.8 is only partially met.

The criterion's full text: "An architecture test asserts ModelContextProtocol.* is referenced by the Mcp module and by no other package, and that no Platform public type exposes, returns, accepts or derives from an SDK type."

PR #220 proves the containment half only — no package outside Mcp references the SDK, and no Platform public type's surface names an SDK type (SdkReferenceGuard/SdkTypeSurfaceGuard in PackageGraphTests.cs, each proven first against a deliberately-broken fixture). It does not add the actual ModelContextProtocol.Core package reference to Mcp — nothing in S14's acceptance criteria requires invoking the SDK, and an unused PackageReference would produce no real assembly reference for the test to check against.

The "referenced by Mcp" half becomes checkable once S15 ("Mcp: the transport, the connection principal and invocation") wires in the SDK's transport alongside its first real use. Left open here for visibility rather than reopening the issue, per repository owner's call.