## ADDED Requirements

### Requirement: MCP tools for skill discovery and retrieval
The system SHALL expose `list_skills`, `search_skills`, and `get_skill` as MCP tools on the same MCP server surface used for device capabilities, so an LLM client can discover and fetch Skill content using the same tool-calling mechanism it already uses for device actions.

#### Scenario: LLM lists available skills
- **WHEN** an MCP client calls `list_skills`
- **THEN** it receives the set of skills currently visible to it (per subscription visibility), each with id, name, description, kind, and tags, without any Subscription Platform-specific fields or identifiers

#### Scenario: LLM searches for a relevant skill
- **WHEN** an MCP client calls `search_skills` with a query string
- **THEN** it receives matching skills ranked/filtered by relevance to the query, using the same visibility rules as `list_skills`

#### Scenario: LLM fetches a specific skill's content
- **WHEN** an MCP client calls `get_skill` with a skill id
- **THEN** it receives the full skill content appropriate to its kind: `content` text for a `knowledge` skill, or `steps`/`parameters` for a `flow_template` skill

### Requirement: Flow-template parameter resolution helper
The system SHALL provide an MCP-facing helper that, given a flow-template skill id and a set of proposed parameter values, validates the values against the skill's declared `parameters` schema and returns the fully resolved step sequence (placeholders substituted) for the LLM to then execute step-by-step via the existing device-capability tools.

#### Scenario: Valid parameters resolve the template
- **WHEN** the LLM provides values for all required parameters of a flow-template skill
- **THEN** the system returns the ordered steps with all `{param}` placeholders substituted by the provided values

#### Scenario: Missing required parameter
- **WHEN** the LLM omits a required parameter when resolving a flow-template skill
- **THEN** the system returns a clear validation error identifying the missing parameter(s) instead of returning a partially-substituted step list

### Requirement: No server-side flow execution tool
The system SHALL NOT expose an MCP tool that executes a flow-template skill's full step sequence server-side on the LLM's behalf; the LLM SHALL issue each resulting device-capability tool call itself so every step remains subject to the existing Agent Runtime's Observe-Think-Act loop and Executor retry/wait handling.

#### Scenario: No batch-execute tool is available
- **WHEN** the MCP tool list is inspected
- **THEN** it contains skill discovery/retrieval/resolution tools but no tool that both resolves and executes a flow-template skill's steps in a single call

### Requirement: Skill MCP errors are semantic
The system SHALL translate catalog-level errors (skill not found, skill not visible/entitled, invalid/unavailable flow template) into clear, semantic MCP tool error responses, consistent in style with the device-capability tool error handling.

#### Scenario: Requesting a non-visible skill
- **WHEN** `get_skill` is called with a skill id that exists but is not visible to the caller's current subscriptions
- **THEN** the tool returns a semantic "not found" error rather than a raw database or internal exception