[MCP-04] Package, version, and test MCP compatibility against sandbox

[jaavid]

Background

CoreLink is one product across multiple implementation repositories. This work is owned by mcp-server under EPIC-05.

Problem

MCP-04 previously depended only on MCP-02, MOCK-03 and left downstream outcomes unresolved. That was insufficient for an RC-oriented package/compatibility gate because security provenance, package maturity and documentation consumers were not explicit.

Goal

Package, version, and test MCP compatibility against the accepted sandbox/mock path with immutable provenance and retained Release Candidate evidence.

Parent

• Primary Product Epic: EPIC-05
• Backlog ID: MCP-04

Scope

• Package/version the accepted MCP read-only tool surface.
• Validate compatibility against the accepted mock/sandbox and version-identifiable API/documentation inputs.
• Carry MCP-01 authorization/consent/audit boundaries into package defaults and examples.
• Distinguish scaffold/prerelease/RC support claims.
• Retain package, dependency, conformance and compatibility evidence.

Out of Scope

• Treating MCP-03 state-changing tools as part of the supported RC surface unless separately accepted.
• Stable claims for contract/tool dependencies that remain draft or scaffold.
• Bypassing public APIs/contracts with internal runtime access.

Acceptance Criteria

• MCP package/version is reproducible and identifies immutable source/dependency revisions.
• Supported read-only tools correspond to the accepted MCP-02 scope and version-identifiable contract/documentation inputs.
• MCP-01 authorization, consent, audit and tenant boundaries are preserved in packaged behavior and examples.
• Compatibility passes against MOCK-03 or an equivalent accepted sandbox for positive, denied, malformed and recovery paths.
• State-changing MCP-03 functionality is excluded unless separately accepted and explicitly versioned.
• Prerelease versus RC/stable maturity is explicit in package metadata and docs.
• Retained evidence is linked and EPIC-05 compatibility/release criteria are measurably advanced.

Dependencies and acceptance state

• Security prerequisite: MCP-01 accepted threat/authorization boundary.
• Execution prerequisite: MCP-02 accepted read-only tool scope.
• Conformance prerequisite: MOCK-03 or an equivalent accepted sandbox/package revision.
• Optional Post-Beta surface: MCP-03 is not required for the read-only RC package unless Product Council explicitly includes it.
• Blocks: DOCS-04 MCP release guidance, WEB-03 supported-tool claims, compatibility/release evidence for PLAT-15 where MCP is included, and EPIC-05 MCP release acceptance.
• Current dependency state: See the CoreLink Product organization Project.

Planning Metadata

• Type: Technical Task
• Priority snapshot: P1
• Product milestone snapshot: Release Candidate
• Domain snapshots: devex, deployment
• Area snapshot: package
• Complexity: M
• Created in status: Triage
• Current status and DRI: See the CoreLink Product organization Project.
• Intended repository labels: type:technical-task

Definition of Done

• Acceptance criteria demonstrated.
• Package/version provenance and reproducibility are verified.
• Required sandbox/conformance checks pass.
• MCP-01 security/tenant boundaries are accepted.
• Contract/tool compatibility and maturity claims are reconciled.
• Packaging/signing/rollback or deprecation behavior is documented where applicable.
• Documentation/release notes are updated.
• Pull request(s), package revision and retained evidence are linked.