Change is complete (24/24 tasks) per its declared scope (read-only local catalog + MCP tools + sync client contract). Management UI and the upstream Subscription Platform were explicitly out of scope. Deltas synced into three new main specs: skill-catalog, skill-mcp-tools, skill-subscription-sync. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.5 KiB
skill-mcp-tools Specification
Purpose
Exposes Skill Catalog discovery, retrieval, and flow-template parameter resolution as MCP tools on the same surface used for device capabilities, so an LLM client can discover and use Skills through the existing tool-calling mechanism.
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_skillswith 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_skillwith a skill id - THEN it receives the full skill content appropriate to its kind:
contenttext for aknowledgeskill, orsteps/parametersfor aflow_templateskill
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_skillis 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