# Domain — Shared Packages + SDKs (MCP + A2A Opportunities)

## Why packages/SDKs matter for MCP/A2A

They define:

- the **portable contracts** (telemetry event schema, diagnostics types)
- the **client integration points** (Swift/Kotlin SDKs, TS client packages)
- reusable primitives (offline queue, platform client)

MCP/A2A should treat these as _the single source of truth_ for:

- schemas
- naming conventions
- safety constraints (no PII)

## Key packages and how to leverage them

### `@bytelyst/telemetry-client`

- Already provides a browser/RN-safe client.
- MCP can expose resources:
  - event schema
  - recommended module/eventName conventions

**Opportunity:** add a companion “policy-aware client” mode that calls `GET /telemetry/config` and samples accordingly.

**Note:** `platform-service` already exposes `GET /api/telemetry/config` (ETag-based). The remaining work is wiring the client to consume it safely.

### `@bytelyst/diagnostics-client`

- Provides session polling + capture utilities.

**Gap (must fix before relying on it):** the client currently flushes batches to `POST /api/diagnostics/ingest`, while `platform-service` routes are session-scoped:

- `POST /api/diagnostics/sessions/:id/logs`
- `POST /api/diagnostics/sessions/:id/traces`
- `POST /api/diagnostics/sessions/:id/screenshots` (SAS upload)

Decision: update `@bytelyst/diagnostics-client` to post to the session-scoped endpoints (no backwards-compat alias endpoint needed).

**Opportunity:** standardize how product apps integrate it (common initialization patterns and user-consent prompts).

### `@bytelyst/platform-client`

- Typed fetch wrapper with auth injection.

**Opportunity:** use it as the basis for a _frontend-side_ MCP client (where appropriate) and for consistent request-id propagation.

### `@bytelyst/offline-queue`

- Good candidate for A2A workflows that need reliable retries.

### Swift / Kotlin Platform SDKs

- Already provide consistent platform-service integration.

**Opportunity:**

- expose SDK version + capabilities as MCP resources
- keep a “compatibility matrix” resource (which products use which SDK features)

## MCP resources recommended from packages

- `schemas.telemetry` (from shared types)
- `schemas.diagnostics` (from shared types)
- `sdk.swift.capabilities`
- `sdk.kotlin.capabilities`

## A2A workflows

### 1) Cross-repo integration audit

- Identify product repos that drift from shared SDK patterns.
- Output: a per-repo “alignment report” and suggested PRs.

### 2) Release impact analysis

- When changing a shared package:
  - agent enumerates downstream consumers
  - runs typecheck/build matrix
  - updates docs + versioning
