[MCP-02] Deliver read-only contract, documentation, device, and telemetry tools

[jaavid]

Background

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

Problem

MCP-02 previously depended on the vague phrase supported APIs, which did not identify which read-only tool surfaces can be implemented now versus which require accepted/version-identifiable contracts before they may be advertised as supported.

Goal

Deliver read-only contract, documentation, device and telemetry MCP tools with explicit authorization, immutable contract provenance and retained Beta conformance evidence.

Parent

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

Scope

• Expose read-only contract/documentation discovery tools.
• Expose supported tenant-scoped device and telemetry read operations.
• Enforce the MCP-01 threat model, explicit tenant context, least privilege and auditable authorization decisions.
• Pin supported tool behavior to version-identifiable API/documentation revisions.
• Retain positive/denied/error/recovery evidence against an accepted mock/sandbox path.

Out of Scope

• State-changing operations; those remain under MCP-03.
• Advertising draft/scaffold tools as supported.
• Bypassing public contract boundaries with internal runtime access.

Acceptance Criteria

• Contract/documentation tools identify exact source revision/maturity and do not invent support claims.
• Device/telemetry read tools map to accepted, version-identifiable API-02 slices where applicable.
• Tenant and scope boundaries are explicit; cross-tenant/unauthorized reads fail closed and are auditable.
• Expected, denied, malformed and recovery paths are repeatable against MOCK-02/MOCK-03 or an equivalent accepted sandbox.
• No state-changing side effect exists in the MCP-02 tool surface.
• Examples/documentation identify MCP and API versions/maturity.
• Retained evidence is linked and EPIC-05 exit criteria are measurably advanced.

Dependencies and acceptance state

• Security prerequisite: MCP-01 threat model and authorization/consent/audit boundary.
• Contract inputs: accepted/version-identifiable API-02 slices for supported device/telemetry tools; documentation/contract discovery may expose draft material only when maturity is explicit.
• Conformance input: MOCK-02/MOCK-03 or an equivalent accepted sandbox before Beta support claims.
• Blocks: MCP-04 package/sandbox compatibility, DOCS-04 MCP guidance, WEB-03 supported-tool claims and EPIC-05 MCP acceptance.
• Current dependency state: See the CoreLink Product organization Project.

Planning Metadata

• Type: Feature
• Priority snapshot: P1
• Product milestone snapshot: Beta
• Domain snapshots: devex, api
• Area snapshot: backend
• Complexity: L
• Created in status: Triage
• Current status and DRI: See the CoreLink Product organization Project.
• Intended repository labels: type:feature

Definition of Done

• Acceptance criteria demonstrated.
• MCP-01 security boundary is accepted or explicitly waived.
• Supported operations map to accepted/version-identifiable inputs.
• Conformance evidence passes for positive and denied paths.
• Tenant/security boundaries are reviewed.
• Documentation/maturity claims are reconciled.
• Pull request(s), dependency versions and retained evidence are linked.